Per anni la stampa ha scritto sul problema che ora ci sono pochissimi indirizzi IPv4 disponibili. D'altra parte, sto usando una società di hosting di server che distribuisce volentieri indirizzi IPv4 pubblici per una piccola somma di denaro. E la mia connessione Internet privata viene fornita con un indirizzo IPv4 pubblico.

Come è possibile? Il problema è grave come la stampa vuole farci credere?

È proprio cattivo. Ecco un elenco di esempi di ciò che ho esperienza diretta con gli ISP dei consumatori per combattere la carenza di indirizzi IPv4:

• Mescolando ripetutamente attorno ai blocchi IPv4 tra le città causando brevi interruzioni e ripristini della connessione per i clienti.
• Riduzione dei tempi di leasing DHCP da giorni a minuti.
• Consentire agli utenti di scegliere se desiderano o meno la traduzione dell'indirizzo di rete (NAT) sull'apparecchiatura locale del cliente (CPE), quindi attivarla retroattivamente per tutti.
• Abilitazione di NAT su CPE per i clienti che hanno già sfruttato l'opportunità di rinunciare a NAT.
• Riduzione del limite al numero di indirizzi MAC (Media Access Control) contemporaneamente attivi applicati da CPE.
• Distribuire NAT (CGN) di livello carrier per i clienti che avevano un indirizzo IP reale al momento dell'iscrizione al servizio.

Tutto ciò sta riducendo la qualità del prodotto che l'ISP sta vendendo ai propri clienti. L'unica spiegazione ragionevole del perché dovrebbero fare questo ai loro clienti è la carenza di indirizzi IPv4.

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

• Spese generali amministrative che non solo costano tempo e denaro, ma sono anche soggette a errori e hanno portato a interruzioni.
• Ampio utilizzo della capacità di memoria indirizzabile dei contenuti (CAM) sui router backbone che qualche anno fa porta a un'interruzione significativa tra più ISP quando supera il limite di un modello di router particolarmente popolare.

Senza NAT non c'è modo di sopravvivere oggi con i 3700 milioni di indirizzi IPv4 instradabili. Ma NAT è una soluzione fragile che ti offre una connettività meno affidabile e problemi difficili da eseguire il debug. Più strati di NAT sono, peggio sarà. Due decenni di duro lavoro hanno fatto funzionare un singolo strato di NAT, ma abbiamo già superato il punto in cui un singolo strato di NAT era sufficiente per ovviare alla carenza di indirizzi IPv4.

Prima di iniziare a rimanere senza indirizzi IPv4, non abbiamo (ampiamente) utilizzato NAT. Ogni computer connesso a Internet avrebbe il proprio indirizzo univoco a livello globale. Quando è stato introdotto NAT per la prima volta, si è passati dal fornire ai clienti dell'ISP 1 indirizzo reale per dispositivo utilizzato / posseduto dal cliente al dare a 1 cliente 1 indirizzo reale. Ciò ha risolto il problema per un po '(anni) mentre dovevamo passare a IPv6. Invece di passare a IPv6, (principalmente) tutti hanno aspettato che tutti gli altri cambiassero e quindi (principalmente) nessuno ha implementato IPv6. Ora stiamo riscontrando nuovamente lo stesso problema, ma questa volta viene distribuito un secondo livello di NAT (CGN) in modo che gli ISP possano condividere 1 indirizzo reale tra più clienti.

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

Ma direi che NAT è terribile, specialmente nel caso in cui l'utente finale non ne abbia il controllo. E (come persona il cui lavoro è ingegneria di rete / amministrazione ma ha una laurea in ingegneria del software), direi che implementando NAT anziché IPv6, gli amministratori di rete hanno spostato il peso della risoluzione dell'esaurimento degli indirizzi fuori dal loro campo e verso gli utenti finali e sviluppatori di applicazioni.

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

Vediamo se posso rendergli giustizia spiegando cosa si rompe (e quali problemi provoca a cui siamo così abituati che non ci rendiamo nemmeno conto che potrebbe essere migliore):

• Indipendenza a livello di rete
• Connessioni peer to peer
• Denominazione coerente e posizione delle risorse
• Instradamento ottimale del traffico, host che conoscono il loro indirizzo reale
• Tracciamento della fonte di traffico dannoso
• Protocolli di rete che separano i dati e controllano in connessioni separate

Vediamo se riesco a spiegare ciascuno di questi elementi.

Indipendenza a livello di rete

Si suppone che gli ISP passino semplicemente intorno ai pacchetti di livello 3 e non si preoccupino di ciò che si trova nei livelli sopra. Sia che tu stia passando per TCP, UDP o qualcosa di meglio / più esotico (SCTP forse? O anche qualche altro protocollo che è migliore di TCP / UDP, ma è oscuro a causa della mancanza di supporto NAT), il tuo ISP non dovrebbe cura; dovrebbe solo assomigliare a dei dati.

Ma non lo è - non quando stanno implementando la "seconda ondata" di NAT, "Carrier Grade" NAT. Quindi devono necessariamente esaminare e supportare i protocolli di livello 4 che si desidera utilizzare. In questo momento, ciò significa praticamente che puoi usare solo TCP e UDP. Altri protocolli verrebbero semplicemente bloccati / eliminati (la stragrande maggioranza dei casi nella mia esperienza) o semplicemente inoltrati all'ultimo host "all'interno" del NAT che utilizzava quel protocollo (ho visto 1 implementazione che lo fa). Anche l'inoltro all'ultimo host che ha utilizzato quel protocollo non è una vera correzione: non appena due host lo utilizzano, si interrompe.

Immagino che ci siano alcuni protocolli sostitutivi per TCP e UDP che sono attualmente non testati e inutilizzati 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 oggi utilizziamo Internet. Ma chi sa cosa ci siamo persi? Ho letto di SCTP e suona bene, ma non l'ho mai usato perché non era pratico a causa della NAT.

Connessioni peer to peer

Questo è grande. In realtà, il più grande secondo me. Se si hanno due utenti finali, entrambi dietro il proprio NAT, indipendentemente dal fatto che uno tenti di connettersi per primo, il NAT dell'altro utente lascerà cadere il pacchetto e la connessione non avrà esito positivo.

Ciò riguarda i giochi, la chat vocale / video (come Skype), l'hosting dei propri server, ecc.

Ci sono soluzioni alternative. Il problema è che queste soluzioni alternative costano tempo per gli sviluppatori, tempo per l'utente finale e inconvenienti o costi di infrastruttura di servizio. E non sono infallibili e talvolta si rompono. (Vedi i commenti degli altri utenti sull'interruzione subita da Skype.)

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

Un'altra soluzione alternativa consiste nell'aggiungere supporto per cose come la perforazione delle applicazioni e mantenere l'infrastruttura del server che non è dietro un NAT per introdurre due client NAT. Questo di solito costa tempo di sviluppo e mette gli sviluppatori in grado di mantenere potenzialmente l'infrastruttura del server dove non sarebbe stato richiesto in precedenza.

(Ricordi cosa ho detto sull'implementazione di NAT anziché su IPv6 spostando il peso del problema dagli amministratori di rete agli utenti finali e agli sviluppatori di applicazioni?)

Denominazione / posizione coerente delle risorse di rete

Poiché all'interno di un NAT viene utilizzato uno spazio di indirizzi diverso rispetto all'esterno, qualsiasi servizio offerto da un dispositivo all'interno di un NAT ha più indirizzi per raggiungerlo e quello corretto da utilizzare dipende da dove il client accede ad esso . (Questo è ancora un problema anche dopo che il port forwarding funziona.)

Se si dispone di un server Web all'interno di un NAT, dire 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 imposta il port forwarding per la porta TCP 80, ora il proprio è possibile accedere al server web usando la porta 80.12.0.23 192 O la porta 80.72.216.228 80. La porta da utilizzare dipende dal fatto che ci si trovi all'interno o all'esterno del NAT. Se si è al di fuori del NAT e si utilizza l'indirizzo 192.168.0.23, non si arriva a dove ci si aspetta. Se ti trovi all'interno del NAT e utilizzi l'indirizzo esterno 35.72.216.228, potresti arrivare dove vuoi, se l'implementazione NAT è avanzata e supporta la forcina, ma il server web che serve la tua richiesta vedrà la richiesta come proveniente dal tuo dispositivo NAT. Ciò significa che tutto il traffico deve passare attraverso il dispositivo NAT, anche se esiste un percorso più breve nella rete dietro il NAT, e significa che i log sul server Web diventano molto meno utili perché elencano tutti il ​​dispositivo NAT come fonte di la connessione. Se l'implementazione NAT non supporta la forcina, non arriverai dove ti aspettavi di andare.

E questo problema peggiora non appena si utilizza DNS. Improvvisamente, se vuoi che tutto funzioni correttamente per qualcosa ospitato dietro NAT, vorrai dare risposte diverse sull'indirizzo del servizio ospitato all'interno di un NAT, in base a chi lo sta chiedendo (AKA split horizon DNS, IIRC). Che schifo.

E questo è tutto supponendo che tu abbia qualcuno che conosca il port forwarding, il NAT tornante e il DNS split horizon. E gli utenti finali? Quali sono le loro possibilità di avere tutto pronto quando acquistano un router di consumo e alcune telecamere di sicurezza IP e vogliono che "funzioni"?

E questo mi porta a:

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

Come abbiamo visto, anche con un avanzato traffico NAT a forcina non sempre scorre il percorso ottimale. Ciò vale anche nel caso in cui un amministratore esperto installi un server e disponga di un NAT a forcina. (Concesso, il DNS split horizon può portare a un routing 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 non specializzati nella configurazione di apparecchiature di rete? In particolare, cosa succede quando inserisco un file da 4 GB nel mio file di condivisione e quindi provo ad accedere al computer successivo? Viene trasferito direttamente tra le macchine o devo attendere che venga caricato su un server cloud tramite una connessione WAN lenta e quindi attendere una seconda volta il download tramite la stessa connessione WAN lenta?

Per un'implementazione ingenua, sarebbe caricato e quindi scaricato, utilizzando l'infrastruttura del server Dropbox che non è dietro un NAT come mediatore. Ma se le due macchine potessero solo rendersi conto che si trovano sulla stessa rete, potrebbero semplicemente trasferire il file direttamente molto più velocemente. Quindi per il nostro primo tentativo di implementazione meno ingenuo, potremmo chiedere al sistema operativo quale indirizzo IP (v4) ha la macchina, e quindi verificare che con altre macchine registrate sullo stesso account Dropbox. Se è nella nostra stessa gamma, trasferisci direttamente il file. Ciò potrebbe funzionare in molti casi. Ma anche allora c'è un problema: NAT funziona solo perché possiamo riutilizzare gli indirizzi. E se l'indirizzo 192.168.0.23 e 192.168.0. 42 indirizzi registrati sullo stesso account Dropbox sono effettivamente su reti diverse (come la tua rete domestica e la tua rete di lavoro)? Ora devi tornare indietro sull'uso dell'infrastruttura del server Dropbox per mediare. (Alla fine, Dropbox ha cercato di risolvere il problema facendo in modo che ciascun client Dropbox trasmettesse sulla rete locale nella speranza di trovare altri client. Ma quelle trasmissioni non attraversano alcun router che potresti avere dietro il NAT, il che significa che non è una soluzione completa ,specialmente nel caso di CGN .)

IP statici

Inoltre, poiché la prima carenza (e ondata di NAT) si è verificata quando molte connessioni del consumatore non erano sempre su connessioni (come il dialup), gli ISP potevano fare un uso migliore dei loro indirizzi allocando gli indirizzi IP pubblici / esterni solo quando si era effettivamente connessi. Ciò significa che quando ti sei connesso, hai ottenuto qualunque indirizzo fosse disponibile, invece di ottenere sempre lo stesso. Ciò rende molto più difficile l'esecuzione del proprio server e rende più difficile lo sviluppo di applicazioni peer-to-peer perché devono gestire i peer che si spostano invece di trovarsi ad indirizzi fissi.

Offuscamento della fonte di traffico dannoso

Poiché NAT riscrive le connessioni in uscita come se provenissero dal dispositivo NAT stesso, tutto il comportamento, buono o cattivo, viene inserito in un indirizzo IP esterno. Non ho visto alcun dispositivo NAT che registra ogni connessione in uscita per impostazione predefinita. Ciò significa che, per impostazione predefinita, l'origine del traffico dannoso passato può essere rintracciata solo sul dispositivo NAT che ha attraversato. Mentre è possibile configurare più apparecchiature di classe enterprise o carrier per registrare ogni connessione in uscita, non ho visto alcun router consumer che lo fa. Sicuramente penso che sarà interessante vedere se (e per quanto tempo) gli ISP manterranno un registro di tutte le connessioni TCP e UDP fatte tramite CGN mentre le implementano. Tali registri sarebbero necessari per gestire i reclami per abuso e reclami DMCA.

Alcune persone pensano che NAT aumenti la sicurezza. Se lo fa, lo fa attraverso l'oscurità. Il calo predefinito del traffico in entrata che NAT rende obbligatorio è lo stesso di avere un firewall con stato. Comprendo che qualsiasi hardware in grado di eseguire il tracciamento della connessione necessario per NAT dovrebbe essere in grado di eseguire un firewall con stato, quindi NAT non merita davvero 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 esegue questa operazione deve avere un software di supporto chiamato ALG (gateway del livello applicazione) su ciascun dispositivo NAT che attraversa, o aggirare il problema con una sorta di mediatore o perforazione. Nella mia esperienza, gli ALG sono raramente se mai aggiornati e sono stati la causa di almeno un paio di problemi che ho affrontato coinvolgendo SIP. Ogni volta che sento qualcuno riferire che il VoIP non ha funzionato per loro perché l'audio ha funzionato solo in un modo, sospetto immediatamente che da qualche parte c'è un gateway NAT che fa cadere pacchetti UDP con cui non riesce a capire cosa fare.

In sintesi, NAT tende a rompersi:

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

Fondamentalmente, l'approccio stratificato adottato dallo stack di rete è relativamente semplice ed elegante. Prova a spiegarlo a qualcuno che non conosce la rete e inevitabilmente presumono che la loro rete domestica sia probabilmente una buona e semplice rete da cercare di capire. Ho visto questo condurre in un paio di casi ad alcune idee piuttosto interessanti (eccessivamente complicate) su come funziona il routing a causa della confusione tra indirizzi esterni e interni.

Ho il sospetto che senza NAT, il VoIP sarebbe onnipresente e integrato con il PSTN e che effettuare chiamate da un telefono cellulare o da un computer sarebbe gratuito (ad eccezione di Internet per cui hai già pagato). Dopotutto, perché dovrei pagare per il telefono quando io e te possiamo semplicemente aprire un flusso VoIP 64K e funziona esattamente come il PSTN? Sembra che oggi, il problema numero 1 con la distribuzione di VoIP passi attraverso i dispositivi NAT.

Ho il sospetto che di solito non ci rendiamo conto di quante più semplici cose potrebbero essere se avessimo la connettività end-to-end interrotta da NAT. Le persone continuano a inviare per e-mail (o Dropbox) stessi file perché se il problema principale è la necessità di un mediatore per quando due client sono dietro NAT.

Un grande sintomo dell'esaurimento di IPv4 che non ho visto menzionato in altre risposte è che alcuni fornitori di servizi mobili hanno iniziato a utilizzare IPv6 solo diversi anni fa. C'è una possibilità che usi IPv6 da anni e non lo sapevi nemmeno. I provider di telefonia mobile sono più recenti del gioco su Internet e non hanno necessariamente enormi allocazioni IPv4 preesistenti da cui attingere. Richiedono anche più indirizzi di cavo / DSL / fibra, poiché il telefono non può condividere un indirizzo IP pubblico con altri membri della famiglia.

La mia ipotesi è IaaS e i fornitori di PaaS saranno i prossimi, a causa della loro crescita che non è legata agli indirizzi fisici dei clienti. Non sarei sorpreso di vedere presto i fornitori IaaS che offrono solo IPv6 con uno sconto.

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

Esistono scenari in cui è preferibile avere un IP IPv4 pubblico dedicato ma non è assolutamente essenziale. Ci sono anche un sacco di indirizzi IPv4 pubblici che sono assegnati ma non attualmente in uso su Internet pubblico (potrebbero essere in uso su reti private o potrebbero non essere affatto in uso). Infine ci sono reti più vecchie con indirizzi assegnati molto più liberamente di quanto debbano essere.

I tre più grandi RIR ora consentono di vendere gli indirizzi sia tra i loro membri che tra loro. Quindi abbiamo un mercato tra le organizzazioni che hanno indirizzi che non stanno usando o che hanno indirizzi che potrebbero essere liberati per un costo da un lato e le 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 prezzo e quindi cosa farà il prezzo di mercato in futuro. Finora il prezzo per PI sembra essere rimasto sorprendentemente basso.

Idealmente, ogni host su Internet dovrebbe essere in grado di ottenere un indirizzo IP di portata globale, tuttavia l'esaurimento dell'indirizzo IPv4 è reale, infatti ARIN ha già esaurito l'indirizzo nel proprio pool gratuito .

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

L'ISP veniva utilizzato per distribuire blocchi di 256 indirizzi IP alle aziende. Ora, gli ISP sono avari e ti danno (una società) come 5. Nel passato (2003), ogni PC e dispositivo connesso nella tua casa aveva il suo indirizzo IP Internet. Ora, il router via cavo / DSN / Fios ha un indirizzo IP e fornisce indirizzi IP 10.0.0.x a tutti i PC di casa. Riepilogo: l'ISP è abituato a perdere indirizzi IP e ora non li spreca più.

Hai già ricevuto molte risposte eccellenti, ma vorrei aggiungere qualcosa che non è stato ancora menzionato.

Sì, l'esaurimento dell'indirizzo IPv4 è negativo, a seconda di come lo si misura. Alcune aziende hanno ancora una grande quantità di indirizzi IPv4, ma stiamo iniziando a vedere soluzioni alternative come NAT di livello carrier.

Ma molte delle risposte sono errate quando si spostano in IPv6.

Ecco un elenco di tecnologie che possono aiutare a gestire la carenza di indirizzi IPv4. Ognuno ha i suoi vantaggi e svantaggi.

• IPv6

  • Vantaggio: standardizzato e disponibile nella maggior parte dei sistemi operativi.
  • Svantaggio: nonostante le frequenti dichiarazioni contrarie, gravi problemi di sicurezza. Già nel 2005, il CERT degli Stati Uniti ha avvertito di problemi di sicurezza causati dall'indirizzamento globale di IPv6. IPv6 può essere protetto correttamente, ma, dato lo stato dei router consumer, potrebbe non accadere.
  • Svantaggio: la migrazione richiede tempo, denaro ed esperienza.
  • Svantaggio: molti dispositivi di fascia consumer sono gravemente difettosi. Ad esempio, numerosi router D-Link supportano IPv6 semplicemente inoltrando tutto il traffico senza offrire firewall.

Un'altra considerazione: anche se IPv6 ha funzionato completamente oggi, ci vorrebbero ancora altri 20 anni per eliminare gradualmente IPv4, a causa delle apparecchiature legacy che le persone useranno per molto tempo (vedo ancora server Windows 2003 e workstation Windows XP occasionalmente! Per non parlare di tutte le stampanti e fotocamere e gadget IoT che non supportano IPv6).

• CGNat:
  • Vantaggio: funziona senza modifiche nei locali del cliente.
  • Svantaggio: supporta solo connessioni in uscita.
  • Svantaggio: potrebbe non supportare alcuni protocolli.

Alla fine, CGNat non sarà abbastanza. Forse IPv6 prenderà piede, ma è anche abbastanza probabile che finiremo per vedere NAT di livello nazionale, o qualcosa del genere.

Attualmente, come consulente, devo spesso segnalare ai miei clienti che sono esposti su IPv6 (spesso grazie a Teredo). La prossima domanda sarà invariabilmente: "quanto costa risolverlo?" e poi "Quanto costa bloccarlo? Cosa perdiamo se lo disattiviamo?" Indovina quale sarà la decisione ogni volta.

In conclusione: per rispondere alla tua domanda, sì, l'esaurimento IPv4 è reale. E vedremo alcuni meccanismi per affrontarlo. IPv6 può o meno finire per essere l'equazione.

Per essere chiari: non sto dicendo che mi piace questa situazione. Vorrei che IPv6 avesse successo (e vorrei vedere una serie di miglioramenti a IPv6). Sto solo guardando la situazione come è sul terreno in questo momento.

NAT è ciò che è accaduto quando IPv6 era un'idea, prima che fosse realtà, e l'allocazione dell'indirizzo IP stava diventando un vero problema (qualcuno ricorda quando stavano distribuendo la Classe C fondamentalmente per la domanda?) E nel frattempo il mondo reale aveva bisogno di una soluzione .

NAT non è sufficiente per l'IoT. Se l'IoT accadrà, accadrà con IPv6. La natura dell'IoT è più strettamente allineata con il modo in cui il mondo del dialup ha funzionato, tranne per il fatto che ci saranno diversi ordini di grandezza in più dispositivi connessi contemporaneamente.

L'intero problema dell'indirizzo IPv4 è piuttosto contorto. È possibile che alcuni articoli riportino che è esaurito, mentre un altro parla di un gran numero di indirizzi in eccesso (mai utilizzati) venduti da una parte all'altra. La domanda sarebbe: perché questi non sono disponibili per quelli (regioni emergenti e aree rurali dei paesi sviluppati) a corto di loro?

Di seguito è riportato il risultato di uno studio in cui ci siamo avventurati accidentalmente. Non utilizza nient'altro che il protocollo IPv4 originale RFC791 e il blocco indirizzi 240/4 a lungo riservato ma poco utilizzato per espandere il pool IPv4 di 256 milioni di volte. Abbiamo presentato un progetto di proposta chiamato EzIP (fonetico per Easy IPv4) a IETF:

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

Fondamentalmente, l'approccio EzIP non solo risolverà i problemi di carenza di indirizzi IPv4, ma mitigherà ampiamente anche la causa principale delle vulnerabilità della sicurezza informatica, oltre a aprire nuove possibilità per Internet, il tutto all'interno dei confini del dominio IPv4. In effetti, questo schema può essere implementato "di nascosto" per regioni isolate dove necessario. Questi dovrebbero alleviare l'urgenza di distribuire IPv6 per un periodo di tempo apprezzabile e invalidare il mercato di negoziazione degli indirizzi IPv4.

Qualsiasi pensiero o commento sarà molto apprezzato.

Abe (15/07/2018 17:29)

Onestamente, penso che non sia così male come la gente pensa. Sì, forse in alcuni posti, ma non così tanto perché non ci sono abbastanza indirizzi. È perché sono tutti di proprietà. Forse è la mia posizione o qualcosa del genere, ma negli ultimi sette anni circa ho svolto il lavoro IT per un gruppo di piccole e medie imprese e tutte le cose di cui stai parlando sono di solito solo impostazioni standard. Abbastanza facile a meno che tu non abbia un dispositivo schifoso o non ci sia una configurazione di merda con la rete in primo luogo che deve essere risolta.

Personalmente, sto bene con NAT. È un ulteriore livello di protezione, in generale. Almeno devono attraversare un dispositivo aggiuntivo o trovare un modo per dirottare indirettamente la mia connessione. Per quanto riguarda i server in esecuzione, ciò è generalmente al di fuori e / o considerato una violazione del contratto con il tuo ISP a meno che tu non lo paghi. Sicuro che puoi farlo, e probabilmente non ti infastidiranno, ma potrebbero.

Port forwarding e tutto ciò non è esattamente complicato. Ora, forse alcuni dispositivi non sono facili da configurare, ma ciò non è dovuto a IPv4. Offre ancora la massima compatibilità semplicemente perché è onnipresente.

Nessuno in realtà ha bisogno di inviare e-mail e inviare qualcosa a Drop-box o Google Drive o un milione di altri servizi simili non è esattamente scienza missilistica, né lento, al giorno d'oggi. Intendo che tutto si sincronizza. Lo lasci cadere in una cartella. A meno che tu non sia nerd come me e fai tutto con ssh / sftp (okay non tutto ). E se hai qualche motivo per cui vuoi davvero eseguire il tuo server, l'hosting cloud è economico-- Ho un server virtuale dedicato che esegue Linux su un SSD. La larghezza di banda è follemente veloce. Si avvia più velocemente di quanto io possa digitare una freccia su e premere Invio. Ed è scalabile L'intero setup costa tra 5 e 10 dollari al mese, con backup gratuiti e nessuna bolletta elettrica.

Non ho davvero bisogno di una soluzione di rete peer. Anche la maggior parte dei giochi multiutente in questi giorni sono tutti configurati per interagire attraverso un server intermedio, tutti configurati e preconfigurati. D'altra parte, se ciò che sto leggendo in questo post è vero, l'IT sarà sovraffollato ed economico se / quando decollerà IPv6. Perfino i cellulari si stanno avvicinando a velocità simili a fibre. O almeno via cavo.

Se esegui un server interno e devi colpirlo con lo stesso nome di dominio all'interno o all'esterno della tua rete, puoi sempre falsificare il suo indirizzo utilizzando un router basato su Linux e dnsmasq o qualsiasi altra voce personalizzata negli host file per reindirizzarti all'indirizzo locale se ti trovi all'interno.

Davvero, non credo sia desiderabile che ogni dispositivo abbia il proprio indirizzo direttamente aperto in rete. Se qualcuno vuole nascondersi mentre ti attacca, accadrà a prescindere. Ma sei un'anatra seduta se sei solo seduto lì le palle fuori nella brezza aperta. No, prenderò il mio IPv4 e il mio NAT ogni giorno. Ma è bello che sia lì.

Comunque, adesso mi sto addormentando ... probabilmente altro da dire, ma domani verro 'in caso avessi perso qualcosa. Sono sicuro che c'è di più.