Ovviamente, mi rendo conto della necessità di passare a IPv6 su Internet aperto poiché stiamo esaurendo gli indirizzi, ma non capisco davvero perché sia necessario utilizzarlo su una rete interna. Ho fatto zero con IPv6, quindi mi chiedo anche: i firewall moderni non fanno il NAT tra indirizzi IPv4 interni e indirizzi IPv6 esterni?
Mi stavo solo chiedendo da quando ho visto così tante persone alle prese con domande IPv6 qui, e mi chiedo perché preoccuparsi?
Risposte:
Non esiste un NAT per IPv6 (come si pensa comunque al NAT). NAT era una soluzione temporanea di $ EXPLETIVE a IPv4 a corto di indirizzi (un problema che in realtà non esisteva e che era stato risolto prima che NAT fosse mai necessario, ma la cronologia è 20/20). Non aggiunge altro che complessità e farebbe ben poco a parte causare mal di testa in IPv6 (abbiamo così tanti indirizzi IPv6 che li sprechiamo in modo sfacciato). NAT66 esiste ed è pensato per ridurre il numero di indirizzi IPv6 utilizzati da ciascun host (è normale che gli host IPv6 abbiano più indirizzi, IPv6 è in qualche modo diverso da IPv4 in molti modi, questo è uno).
Si supponeva che Internet fosse instradabile end-to-end, questo è uno dei motivi per cui IPv4 è stato inventato e perché ha ottenuto l'accettazione. Ciò non significa che tutti gli indirizzi su Internet dovevano essere raggiungibili. NAT rompe entrambi. I firewall aggiungono livelli di sicurezza interrompendo la raggiungibilità, ma normalmente sono a scapito della instradabilità.
Si desidera IPv6 nelle proprie reti in quanto non è possibile specificare un endpoint IPv6 con un indirizzo IPv4. Il contrario funziona, il che consente alle reti solo IPv6 che utilizzano DNS64 e NAT64 di accedere ancora a Internet IPv4. Oggi è effettivamente possibile abbandonare IPv4 tutti insieme, anche se è un po 'fastidioso configurarlo. Sarebbe possibile eseguire il proxy dagli indirizzi interni IPv4 ai server IPv6. L'aggiunta e la configurazione di un server proxy aggiunge costi di configurazione, hardware e di manutenzione alla rete; di solito molto più che semplicemente abilitare IPv6.
NAT causa anche i propri problemi. Il router deve essere in grado di coordinare ogni connessione che lo attraversa, tenendo traccia di endpoint, porte, timeout e altro. Tutto quel traffico viene normalmente incanalato attraverso quel singolo punto. Sebbene sia possibile costruire router NAT ridondanti, la tecnologia è enormemente complessa e generalmente costosa. I router semplici ridondanti sono facili ed economici (relativamente). Inoltre, per ristabilire parte della instradabilità, è necessario stabilire le regole di inoltro e traduzione sul sistema NAT. Ciò rompe ancora i protocolli che incorporano indirizzi IP, come SIP. UPNP, STUN e altri protocolli sono stati inventati per aiutare anche con questo problema: più complessità, più manutenzione, più cose che potrebbero andare storte .
L'esaurimento degli indirizzi ipv4 interni (rfc1918) può anche essere un motivo molto valido per passare a ipv6.
Comcast ha spiegato a Nanog37 perché stavano andando ipv6 per i loro indirizzi di gestione.
20 Million video customer
x 2.5 STB/customer
x 2 ip addresses/STB
--------------------
= 100 Millions IP addresses
E questo è solo per video , non per dati / modem.
Hanno esaurito i pool RFC1918 nel 2005. Quindi hanno utilizzato pool di indirizzi pubblici (poiché nat non è un'opzione per la gestione) e sono andati su ipv6 per risolvere le loro esigenze .
Coppia di motivi:
IPv6 non supporta la trasmissione. Viene sostituito con il multicasting. La trasmissione consente a un nodo di inviare traffico a tutti i nodi su una sottorete. La gestione dei domini broadcast è un problema importante nel mantenere le reti IPv4 di grandi dimensioni in esecuzione veloce e senza problemi. Il multicast richiede che i nodi che desiderano ricevere lo stile "broadcast" siano effettivamente "registrati", quindi la rete non è invasa da traffico che colpisce tutti gli host.
IPv6 supporta la crittografia in stile IPsec in modo nativo.
IPv6 supporta la configurazione automatica. È possibile per gli host dietro un router configurarsi da soli senza la necessità di DHCP, anche se è ancora necessario un server DHCP per distribuire opzioni DHCP come server DNS, server TFTP, ecc.
Il mio vecchio lavoro, in una grande università, utilizzava un'allocazione IPv6 internamente. A loro è stato assegnato un IPv4 / 16 nel corso della giornata e anche oggi sta distribuendo gli indirizzi IPv4 a quasi tutti i client interni. Le reti RFC1918 erano limitate alla rete solo per telecomunicazioni e ad alcuni usi specializzati (gli standard PCI richiedevano l'utilizzo di RFC1918 fino a ottobre 2010).
Per questo motivo, stavano attivamente pianificando di utilizzare anche IPv6 internamente. C'erano ancora alcuni problemi hardware da risolvere, i edge switch non supportavano abbastanza bene la v6, ma il core era pronto. L'idea era che ottenere il supporto v6 dall'estremità pubblicamente visibile (ok, l' estremità responsive del pubblico ) della rete avrebbe comportato il 70% del lavoro per distribuirlo a tutti, potrebbe anche fare il 30% in più e andare fino in fondo finiscilo.
Avendo vissuto con un'allocazione IP pubblica per così tanto tempo, la nostra gente era molto consapevole dell'adagio: "solo perché è pubblico, non significa che sia raggiungibile". Come ha detto Chris S, il percorso non implica raggiungibile.
Ecco perché almeno una classe di organizzazioni dovrebbe distribuire IPv6 internamente: perché stanno già utilizzando IPv4 non RFC1918 internamente.
IPv6 offre alcuni potenziali miglioramenti del mondo reale rispetto a IPv4, come un più semplice meccanismo di autoconfigurazione e di rilevamento automatico, è anche più sicuro nel senso che diventa impossibile per il malware replicarsi attraverso una rete eseguendo la scansione delle porte in un intervallo IP: - ci sono troppi IP. Ma questi miglioramenti non sono particolarmente drammatici e certamente non valgono il costo di commutazione.
Ma nota che non è né una / né una decisione, puoi eseguirli entrambi in parallelo, e se sviluppi software, probabilmente dovresti, come molte persone hanno detto, a scopo di test. Non esiste un modo affidabile per rendere compatibile un programma IPv6 senza disporre di un'infrastruttura IPv6 interna su cui testare. La maggior parte dei sistemi operativi moderni installerà automaticamente una rete IPv6 interna tra loro - è solo una questione di usarla.
10 anni fa ho creato un po 'di software per un datore di lavoro che i clienti usano per recuperare gli aggiornamenti del programma. Durante la creazione del componente di rete, ho dovuto decidere tra la creazione in compatibilità IPv6 o semplicemente supponendo che tutti gli indirizzi IP fossero 4 byte. Ho deciso di prendere il percorso semplice, risparmiando circa 4 ore di lavoro, e ho reso l'applicazione solo IPv4. Ho pensato che sarebbe stato sostituito tra qualche anno. Lo usano ancora oggi e sono quindi esclusi da alcuni mercati minori.
Lavorando per una piccola azienda, posso solo pensare ai motivi per NON utilizzare IPv6.
Non ha senso che una società come la nostra effettui il cambiamento, poiché richiederebbe notevoli spese e sforzi senza ottenere nulla da essa.
Francamente, mi piace il NAT e i vantaggi che otteniamo dalla gestione degli indirizzi locali. Se mai diventasse necessario (anziché essere un geek desideroso di fare) per noi interagire con IPv6 su Internet, lo faremo al gateway.
Non mi aspetto che l'attuale moda IPv6 diventi una necessità per la stragrande maggioranza del mondo, almeno internamente, per un decennio o più. Dato che mi aspetto di andare in pensione, non ho molti incentivi per me personalmente a perdere tempo e fatica.
Modificare:
Sto ricevendo voti negativi, ma non una singola visione logica e ragionevole opposta. Mi fa pensare che sia solo un gruppo di fanatici del salto del bandwagon che vogliono seguire la tendenza senza pensarci. Ci deve essere un MOTIVO per apportare un cambiamento così drastico a una rete e non ne ho una. Inoltre, sospetto fortemente che solo pochi utenti SF ne abbiano uno.
Stiamo parlando di due cose qui: eseguire la rete interna su IPv6 puro o eseguire dual-stack IPv4 / IPv6. Penso che sia prematuro parlare di eseguire IPv6 puro - su molti sistemi operativi è persino impossibile usare IPv6 senza IPv4. Tuttavia, potresti considerare di eseguire il dual-stack per i seguenti motivi (a) se sviluppi software (b) al fine di preparare la tua rete per l'inevitabile migrazione a IPv6. Se la tua situazione è A, allora dovresti agire ora, se è B allora, secondo la mia stima, hai circa 1-2 anni per pensarci (ma prima inizi, più sarai pronto).
La mia situazione è A e stiamo eseguendo il dual-stack da 6 mesi. Durante questo periodo abbiamo identificato e risolto alcuni problemi con il nostro DNS pubblico / privato, allocazione degli indirizzi, DHCP, routing, firewall e non abbiamo nemmeno potuto anticipare molti di questi problemi senza provare. Ora siamo completamente pronti per IPv6 e abbiamo persino l'accesso pubblico IPv6 tramite tunneling. Dalla mia esperienza posso affermare con sicurezza che IPv6 è una soluzione molto più semplice ed elegante rispetto all'invecchiamento di IPv4, quindi sarò molto felice quando arriverà il momento di passare a IPv6, ma prima che arrivi questo momento - dual-stack è il modo andare.
A parte lo spazio degli indirizzi lager, l'assenza di trasmissione, IPSec e la configurazione automatica più semplice ci sono alcuni vantaggi "non così noti" di IPv6:
Lo spazio di indirizzi più grande significa che l'indirizzo ha più bit che possono essere utilizzati come memoria dati. Ad esempio, il conteggio dei luppoli tra due nodi può quindi essere una funzione dei loro indirizzi IPv6, ad esempio: l'
indirizzo IPv6 può essere in formato, PREFIX:Country&Region:DC&Line:Rack&Unit:VM&IDquindi i nodi più vicini avranno più Bit più significativi. Questo è solo un esempio, ovviamente le metriche di "vicinanza" potrebbero essere archiviate in un qualche tipo di database esterno come i TXT|SRVrecord DNS .
Esistono alcune tecniche di utilizzo dello spazio degli indirizzi di IPv6 per scopi crittografici come Cryptographically Generated Addresses ( CGA ) e SEND (SEcure Neighbor Discovery)
Quando IPv6 è abilitato, tutti i nodi della rete dispongono di un indirizzo IPv6 locale di collegamento (se non configurato diversamente). Quindi c'è la possibilità che tu possa accedere anche al nodo mal configurato.
È possibile ottenere gli indirizzi MAC dei nodi direttamente dall'indirizzo IPv6 locale del collegamento (se le estensioni di privacy IPv6 non sono configurate)
Non è possibile utilizzare IPv4 nelle sottoreti con migliaia di nodi: la rete sarà sovraccaricata di traffico di trasmissione (ad es. ARP).
È possibile eseguire una query sul nodo per ulteriori informazioni utilizzando le informazioni sul nodo , ad esempio in BSD è possibile eseguire una query sull'host per gli indirizzi del nodo Informazioni nodo ICMPv6:
$ ping6 -a Aacgsl ::1
PING6(72=40+8+24 bytes) ::1 --> ::1
136 bytes from ::1:
fe80::beae:c5ff:fe43:44a(TTL=infty)
fe80::beae:c5ff:fe43:212(TTL=infty)
::1(TTL=infty)
fe80::1(TTL=infty)
2a02::9222(TTL=infty)
Posso pensare a due motivi per usare IPv6 per un host interno.
In futuro potresti scoprire che questo host deve essere disponibile esternamente almeno su determinate porte.
È possibile che questo host debba connettersi a un altro host che ha anche scelto lo stesso indirizzo interno. Ad esempio, è necessario connettersi a 10.0.0.5 presso Acme corporation e il proprio indirizzo presso Emca corporation è anche 10.0.0.5. Ricordo che ciò accadeva in un precedente lavoro, entrambi avevamo usato gli stessi indirizzi interni.
Direi che nel mondo moderno la maggior parte dei computer non sono interni al 100%. La maggior parte dei desktop può stabilire connessioni limitate con il mondo esterno o viceversa.
L'unico buon motivo per passare internamente a IPv6 è essere pronti quando il mondo passa a IPv6, e penso che sia un motivo piuttosto negativo, dato il tasso di adozione. Dal momento che la maggior parte degli IP interni non saranno raggiungibili esternamente, non sarebbe molto importante tradurre il resto.
La mia società probabilmente non passerà mai internamente a IPv6. Richiederebbe un cambiamento radicale nella politica così massiccio che non riesco a concepire onestamente come potrebbe accadere. Molte persone dovrebbero essere uccise e molte scelte di assunzione inspiegabili dovrebbero essere fatte. Allo stesso modo, qualsiasi tentativo da parte delle singole unità aziendali di passare a IPv6 sulle loro LAN sarebbe schiacciato con pregiudizio dai signori delle reti aziendali in base a problemi di interoperabilità e di manutenibilità (permettiamo molto margine di manovra a livello locale, ma non così tanto).
Fondamentalmente, se passare a IPv6 fosse indolore, l'avremmo fatto anni fa.
IPv4 intendeva che tutti i dispositivi fossero direttamente su Internet ... fino a quando non rimanemmo esauriti lo spazio degli indirizzi. Quindi, abbiamo trascorso gli ultimi 20 anni a bloccare tutto. Ora, IPv6 di progettazione vuole, ancora una volta, posizionare tutti i dispositivi direttamente su Internet ... il risultato sarà lo stesso. Concordo pienamente sul fatto che NAT sia un livello di sicurezza che non verrà abbandonato senza una sostituzione altrettanto efficace o migliore.
Sfortunatamente, ci sono molte cattive informazioni nella stragrande maggioranza di queste risposte e commenti. È così triste vedere il cieco guidare il cieco in questo modo in modo così prolifico.
Il NAT non va da nessuna parte e le persone che ti dicono "Oh, quel NAT, che cosa terribile è" ... "Oh quel NAT, non era altro che un problema" ... ad nasueum Se iniziano a usare un linguaggio come quello, passare a un vero architetto di rete professionale per un consiglio, non un guerriero di poltrona di rete di fine settimana.
Devi bilanciare il traffico sui server interni da Internet? Beh, indovina un po ', con IPv6 non puoi farlo come lo hai fatto tu .... a meno che tu non usi NAT!
Si è vero. Alcuni diranno, oh, basta usare il bilanciamento del carico di ritorno del server DSR / Direct. Ma si dimenticano di dirti che devi rinunciare 1) Inserimento cookie 2) Accelerazione dell'applicazione 3) Traduzione dell'indirizzo del porto
Quindi, se vuoi eseguire i tuoi server interni sulla porta 8080 ma quello esterno sulla porta 80 ... Oh, così triste, non puoi fare con IPv6 .... a meno che tu non stia usando un buon ole NAT! Nemmeno con DSR.
Quindi aggiungi a questo il "vanto" che la gente dice "Oh, sì, tutte le proposte NAT IPv6 sono fallite ... grazie al cielo" (e l'impero muore al suono di applausi) Sai cosa significa? NAT sarà terribile, se funziona addirittura con IPv6, perché tutti i fanatici di IPv6 negano intrinsecamente la necessità di NAT / PAT e le persone che lo fanno lo fanno con riluttanza. Così triste, così mal gestito
Quindi cosa fai ora che la verità ti ha liberato e puoi elevarti al di sopra delle folle di lemming cercando di usare tattiche spaventose per forzare la tua conformità?
Acquistate o continuate a utilizzare un Loadbalancer o Firewall che funge da intermediario pubblico / privato della vostra rete. Le interfacce lato pubblico ospitano gli stessi VIP che hai già ma con un indirizzo IPv6 complimentoso se ne hai bisogno. Tutto a nord del livello Loadbalancer / Firewall è anche dual stack IPv4 / IPv6. Sulle interfacce interne di Loadbalancer / Firewall sono tutte IPv4 e l'intera rete interna è IPv4 e rimane tale per tutto il tempo che desideri. Sono solo affari tuoi. Loadbalancer esegue NAT / PAT tra l'esterno e l'interno ... perché lo è già e deve farlo per il bilanciamento del carico completo e perché ora risolve anche il problema IPv6 esterno.
Oh, e alla persona sarcastica che ha chiesto "Quale unico scopo di sicurezza serve NAT"
La sicurezza riguarda la disponibilità al livello più fondamentale. Pensaci, prima di respingerlo.
I servizi di bilanciamento del carico forniscono disponibilità / sicurezza e DEVI utilizzare NAT / PAT per farlo correttamente, indipendentemente dalla versione dell'IP che stai utilizzando.
Citazione relativa al DSR fallito: https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return
k thnx
Non è una buona idea usare IPv6 su una rete interna poiché molti dispositivi legacy non riuscirebbero a comunicare. Vecchie fotocopiatrici / stampanti multifunzione, apparecchiature mediche, vecchie macchine da stampa, server più vecchi e dispositivi di rete. Lo schema IPv4 è molto più semplice da gestire imo.
La risposta accettata è fuorviante
I concetti di Chris S su NAT sono sbagliati; una delle migliori caratteristiche di NAT oltre all'espansione artificiale dello schema IPv4 è SICUREZZA. NAT è il livello che nasconde il vero IP di un host che, se collegato direttamente a Internet, può essere il bersaglio di tutti gli attacchi immaginabili. Parlare felicemente di sbarazzarsi di NAT senza incoraggiare ulteriori misure di sicurezza è semplicemente una semplice ignoranza sull'argomento.