Il confronto tra IPv4 o IPv6 non è una questione da puristi di rete: influisce su costi, compatibilità, scalabilità e sulla facilità con cui un servizio resta raggiungibile nel tempo. Io lo tratto sempre come una decisione di architettura, non come una semplice preferenza tecnica, soprattutto quando entrano in gioco mobile, cloud e dispositivi connessi. Qui trovi un confronto pratico su differenze, vantaggi, limiti e convivenza dei due protocolli nelle infrastrutture reali.
I punti da tenere fermi prima di scegliere
- IPv4 resta diffusissimo, ma lo spazio indirizzi è finito e la scarsità ha un costo operativo.
- IPv6 porta 128 bit, niente broadcast e un modello più adatto alla crescita.
- Nella pratica i due protocolli convivono spesso con dual-stack, NAT64 e CGNAT.
- Il problema vero non è solo attivare IPv6, ma farlo senza rompere DNS, firewall e applicazioni.
- Per nuove reti e nuovi servizi, partire con IPv6 oggi riduce debito tecnico e lavoro futuro.
Che cosa cambia davvero tra IPv4 e IPv6
Io vedo due differenze che contano più di tutte: la quantità di indirizzi disponibili e il modello operativo. IPv4 usa indirizzi a 32 bit e, nella pratica, obbliga quasi sempre a introdurre NAT, cioè traduzione di indirizzi per far convivere molti dispositivi su un numero ridotto di IP pubblici. IPv6 usa indirizzi a 128 bit, elimina il collo di bottiglia della scarsità e semplifica alcune parti del percorso dati, anche se richiede una configurazione iniziale diversa.
| Criterio | IPv4 | IPv6 | Impatto pratico |
|---|---|---|---|
| Spazio indirizzi | 32 bit, circa 4,3 miliardi di combinazioni teoriche | 128 bit, uno spazio enorme | IPv6 elimina la scarsità strutturale |
| Header | Minimo 20 byte, con checksum | 40 byte fissi di base, senza checksum header | Parsing più regolare su IPv6 |
| NAT | Molto usato nelle reti grandi | Non indispensabile | Più semplicità end-to-end con IPv6 |
| Broadcast | Presente | Assente, si usano multicast e anycast | Meno traffico inutile e meno rumore di rete |
| Transizione | Maduro ma saturo | Richiede convivenza e migrazione | La fase di adozione va progettata |
Due termini che tornano spesso sono SLAAC, cioè l'autoconfigurazione automatica degli indirizzi senza un server centrale, e DHCPv6, la variante di DHCP pensata per IPv6. Non sono dettagli marginali: cambiano il modo in cui distribuisci gli indirizzi, gestisci i lease e controlli la rete. La parte che spesso viene sottovalutata è la frammentazione: in IPv4 possono frammentare anche i router, mentre in IPv6 la frammentazione viene spostata all'host sorgente e il Path MTU Discovery diventa decisivo.
In altre parole, IPv6 non è solo "più indirizzi": cambia il modo in cui la rete si comporta e il modo in cui va testata. Ed è proprio questa differenza strutturale che rende inevitabile parlare di transizione e convivenza, non di semplice sostituzione.
Perché IPv6 è ormai una scelta operativa
Nel 2026 il tema è già operativo, non teorico: Google misura circa il 48,08% di traffico IPv6, mentre APNIC stima il 43,24% di capacità mondiale. Le due letture non coincidono perfettamente perché usano metodi diversi, ma raccontano la stessa cosa: IPv6 è ampiamente presente e non si può più trattare come un esperimento da laboratorio.
Il motivo di fondo resta semplice. IPv4 offre 232 indirizzi, quindi poco più di 4 miliardi di combinazioni teoriche, e gran parte di quello spazio è già impegnato. Quando gli indirizzi pubblici scarseggiano, si finisce su trasferimenti, lease, subnet più strette o CGNAT, cioè una traduzione condivisa degli indirizzi che salva la connettività ma aggiunge complessità, log e costi operativi. Nelle reti mobili e nei servizi con forte crescita di utenti, questo peso si sente subito.
Qui IPv6 diventa interessante perché facilita la crescita, riduce la dipendenza dalla condivisione degli IP pubblici e rende più lineare l'onboarding di nuovi dispositivi, dai telefoni ai sensori. Io lo considero un prerequisito di modernità della rete, non un optional da rimandare all'infinito. Da qui nasce la domanda pratica: come si fanno convivere i due mondi senza bloccare i servizi esistenti?
Come convivono nella rete reale
Nella pratica non si sostituisce quasi mai tutto in una volta. Si lavora per fasi, e i modelli più usati sono tre: dual-stack, NAT64/464XLAT e alcuni meccanismi di tunneling. La scelta dipende da quanto controllo hai sull'infrastruttura, da quanto sono vecchi i servizi che devi raggiungere e da quanto vuoi spingere la rete verso IPv6.
Dual-stack
Dual-stack significa che host, router e servizi parlano sia IPv4 sia IPv6 nello stesso momento. È la scelta più pulita quando devi garantire compatibilità massima, perché non spezza i servizi esistenti, ma richiede cura doppia su DNS, firewall e monitoraggio. Io la consiglio quando il servizio nasce nuovo oppure quando puoi governare bene l'intera catena, dal client al backend.
NAT64 e 464XLAT
NAT64 traduce traffico da IPv6 verso server IPv4-only. È molto utile quando vuoi una rete IPv6-first o IPv6-only ma devi continuare a raggiungere parte del web o applicazioni che non hanno ancora un endpoint IPv6. 464XLAT aggiunge una traduzione lato client e oggi è particolarmente rilevante su mobile, dove semplifica l'accesso a vecchi servizi senza riportare tutto su IPv4.
Leggi anche: WiFi senza linea fissa - Qual è la scelta giusta per te?
Tunneling e CGNAT
6in4, 6rd e altri tunnel portano pacchetti IPv6 dentro una rete IPv4. Funzionano, ma io li considero strumenti di transizione, non l'assetto finale. CGNAT, invece, è spesso la toppa necessaria quando l'IPv4 non basta più: utile per guadagnare tempo, meno gradevole quando cresce il numero di utenti, i log o le eccezioni da gestire.
Capito il meccanismo, la scelta successiva è meno astratta: in quali casi conviene ancora puntare su IPv4 e in quali su IPv6?Quando usare ancora IPv4 e quando puntare su IPv6
Io non tratto la scelta come binaria. Nella maggior parte dei progetti seri, il punto non è eliminare subito IPv4, ma capire dove serve ancora come strato di compatibilità e dove invece IPv6 può già diventare il default. Questa distinzione evita sia blocchi inutili sia migrazioni affrettate.
| Scenario | Scelta pragmatica | Perché |
|---|---|---|
| Nuovo sito o nuova app | IPv6 attivo subito, con dual-stack se serve copertura massima | Riduci debito tecnico e prepari subito DNS, firewall e monitoraggio |
| Rete aziendale con ERP, VPN o apparati legacy | IPv4 stabile, con pilota IPv6 su segmenti controllati | Proteggi la compatibilità mentre testi il comportamento reale |
| Operatore mobile o ISP | IPv6-first con traduzione verso IPv4 | Scala meglio e limita la pressione su IPv4 e CGNAT |
| Servizio pubblico con utenti misti | Dual-stack ben monitorato | Massima raggiungibilità mentre la base clienti si distribuisce tra i due protocolli |
La mia regola è semplice: se il servizio nasce oggi e deve vivere anni, IPv6 va previsto da subito; se deve agganciarsi a sistemi vecchi o partner non aggiornati, IPv4 resta indispensabile nel breve periodo. Il punto non è scegliere un vincitore assoluto, ma evitare che il traffico futuro dipenda da una rete costruita solo per l'oggi. Ed è qui che emergono gli errori tipici.
Gli errori che vedo più spesso nei progetti di migrazione
La difficoltà di IPv6 viene spesso esagerata, ma i problemi reali nascono quasi sempre da dettagli operativi. Quando una migrazione sembra "complicata", di solito non è il protocollo il colpevole: sono il DNS, le policy di sicurezza, i test incompleti o le dipendenze nascoste nelle applicazioni.
- Attivare IPv6 senza test end-to-end - Il servizio risponde in laboratorio, ma fallisce con client reali o reti diverse. Io verifico sempre risoluzione DNS, connettività e applicazione insieme.
- Pubblicare gli A e dimenticare gli AAAA - Alcuni client preferiscono IPv6 quando lo vedono disponibile. Se non testi bene questo passaggio, rischi percorsi incoerenti e debugging inutile.
- Lasciare il firewall IPv6 più aperto di quello IPv4 - Capita spesso per distrazione. La regola corretta è replicare la postura di sicurezza, non affidarsi al fatto che "tanto è nuovo".
- Ignorare MTU e Path MTU Discovery - Con pacchetti grandi o tunnel in mezzo, i problemi saltano fuori subito. Qui conviene testare con traffico reale, non solo con ping banali.
- Trascurare monitoraggio e log - Se osservi solo IPv4, perdi metà della diagnosi. Io separo sempre dashboard, alert e tracciamento per entrambe le famiglie di indirizzi.
- Usare CGNAT come strategia definitiva - Il CGNAT può comprare tempo, ma non sostituisce un piano IPv6. Più cresce la rete, più aumentano i costi di gestione e le eccezioni.
Questi problemi non rendono IPv6 difficile; mostrano solo che va gestito come progetto di rete e non come spunta in una console. Se devo ridurre tutto a una regola operativa, io la tengo molto semplice: IPv6 prima, compatibilità sempre sotto controllo, e transizione progressiva dove servono sistemi legacy.
La regola pratica che uso nei progetti di connettività
Se devo sintetizzare il lavoro in una formula concreta, parto così: nuove piattaforme con IPv6 per primo, infrastrutture esistenti con IPv4 stabile ma un piano IPv6 misurabile. Prima sistemo DNS, firewall, monitoraggio e dipendenze applicative, poi apro il traffico su entrambi i protocolli in modo controllato. È questo l'approccio che evita sia l'inerzia sia le migrazioni affrettate.
IPv4 serve ancora, ma è sempre più un livello di compatibilità; IPv6 è il protocollo su cui costruire la crescita, non solo la prossima prova di laboratorio. Se la rete deve restare solida nel tempo, la domanda giusta non è più scegliere un lato, ma progettare una convivenza pulita finché IPv6 può diventare il comportamento predefinito.
