Differenza tra IPv4 e IPv6: quello che spesso non ti dicono sulla compatibilità delle reti

Ogni volta che metto mano a una rete aziendale, la domanda è sempre la stessa: come faccio a far convivere servizi vecchi basati su IPv4 con applicazioni nuove che parlano già IPv6 senza rompere nulla? Ne ho viste tante, comprese dorsali montate in fretta durante un blackout di connettività locale. Quello che spesso non viene detto è che la compatibilità non è un interruttore: è una somma di dettagli che, se ignorati, diventano disservizi.

IPv6 non è solo più indirizzi

La differenza non è quantitativa, è culturale. In IPv4 abbiamo fatto pace con il NAT: indirizzi privati dietro un unico IP pubblico e via. Con IPv6 si torna al principio end-to-end: ogni host può essere raggiungibile senza traduzioni. Questo cambia il modo in cui progetti firewall, VPN, bilanciatori e persino applicazioni interne.

Vedo spesso due errori. Primo: abilitare IPv6 e poi replicare regole IPv4 “apri tutto in uscita, blocca in ingresso”. Così perdi il vantaggio della raggiungibilità controllata. Secondo: ignorare come i client ottengono l’indirizzo. SLAAC e DHCPv6 non sono equivalenti a livello operativo: con SLAAC gestisci meno centralmente, con DHCPv6 hai più controllo ma devi curare i relay e i prefix delegations.

Potrebbe interessarti anche

Connessione lenta via cavo? le impostazioni spesso ignorate che fanno la differenzaLa sicurezza delle reti wireless aziendali: errori comuni e la soluzione definitivaCome scegliere il firewall software più adatto alla tua infrastruttura: i criteri tecnici indispensabiliPerché è importante il logging centralizzato nelle reti digitali: ti semplifica il rilevamento degli incidenti

Nota pratica: gli indirizzi temporanei (privacy extensions) confondono i log se non hai un buon sistema di osservabilità. Imposto sempre syslog e NetFlow per tracciare prefissi, non singoli indirizzi.

Compatibilità reale: dove si rompe

In tanti ambienti la compatibilità si gioca su due fronti: quello del provider e quello della LAN. Con alcuni ISP arrivi in Internet via CGNAT per IPv4 e nativo per IPv6. Risultato? Le tue pubblicazioni su IPv4 non sono esposte, le VPN vecchie faticano, e i servizi moderni, se raggiunti in IPv6, filano lisci. Il paradosso è che “tutto sembra andare” finché un flusso specifico non trova un muro.

Mi è capitato di recente in un piccolo studio con tre sedi: il gestionale cloud pubblicava AAAA e A. I PC preferivano IPv6 ma il firewall non ispezionava quel traffico, applicando solo le policy su IPv4. Alcune funzioni di scansione documenti cadevano a caso. Ho unificato le policy su IPv6, aggiornato gli ACL e forzato l’uso di DNS interni coerenti con le zone split-horizon. Tempo totale: due ore. Disservizi azzerati.

Altro classico: il telelavoro. L’utente è dietro CGNAT, il port forwarding per IPv4 è impossibile. Se il tuo server supporta IPv6 e il client anche, la sessione si apre subito. Se non lo supporta, serve un overlay: DS-Lite, 6rd o una VPN moderna che traghetti entrambi gli stack.

Transizione: dual-stack, NAT64/DNS64 e scelte dei client

La via più robusta, quando puoi, è il dual-stack: stessa rete che parla sia IPv4 che IPv6. Il problema è la manutenzione doppia delle policy e l’illusione che “se funziona in v4 allora va bene”. Non sempre. I browser e molte app adottano Happy Eyeballs, che privilegia la connessione più veloce tra A e AAAA: se l’IPv6 è mal configurato, avrai lentezze intermittenti difficili da riprodurre.

In contesti mobile e ISP moderni è comune l’accoppiata NAT64/DNS64: il client ha solo IPv6, ma risolve nomi IPv4 e il traffico viene tradotto. Funziona bene finché l’applicazione non richiede un literal IPv4 o protocolli non TCP/UDP standard. In quei casi, 464XLAT risolve molto, ma va testato.

Le VPN sono un’altra cartina di tornasole: IPSec puro spesso soffre dietro CGNAT e frammentazioni MTU; WireGuard o OpenVPN su UDP vanno meglio, specie se li configuri esplicitamente per trasportare IPv6 end-to-end.

Gli imprevisti più frequenti

MTU e Path MTU Discovery: IPv6 impone 1280 byte minimi. Con tunnel, PPPoE e overlay, la MTU utile scende e se i firewall bloccano gli ICMPv6 “Packet Too Big” hai il classico black hole: ping ok, pagine che non caricano. Io imposto sempre allow-list per ICMPv6 essenziali.

Firewall doppi: molti gestiscono regole IPv4 e IPv6 in sezioni separate. Se non replichi le policy, lasci buchi o crei blocchi inspiegabili. Ho visto applicazioni “sicure” in v4 e completamente esposte in v6 senza che nessuno se ne accorgesse.

DNS e split-horizon: pubblicare un AAAA esterno e dimenticare quello interno manda i client esterni su v6 e gli interni su v4, con latenza e comportamenti diversi. Meglio allineare A/AAAA tra interno ed esterno o usare policy-based DNS.

Email: aggiungere un record AAAA al tuo MX senza configurare correttamente il reverse PTR e gli ACL IPv6 sul mail server è un invito ai rimbalzi. Verifica SPF, DKIM, DMARC anche in v6.

Geolocalizzazione e CDN: alcuni CDN bilanciano in modo diverso tra IPv4 e IPv6. Ti ritrovi a uscire da PoP più lontani in un caso e vicini nell’altro. Osserva i traceroute su entrambi gli stack prima di giudicare la qualità della rete.

VPN legacy: molte soluzioni vecchie incapsulano solo IPv4. Se le usi con dual-stack, l’app raggiunge il server in IPv6 fuori dal tunnel e aggira le policy. Serve o forzare il prefer v4 sulle destinazioni critiche o aggiornare la VPN.

Checklist operativa

• Abilita dual-stack dove possibile e allinea le policy: firewall, NAT, ACL e QoS in versione IPv4 e IPv6.
• Testa sempre con e senza VPN: verifica MTU, ICMPv6, traceroute v4/v6, risoluzioni DNS A/AAAA e tempi con Happy Eyeballs.

Caso reale: dorsale VPN in emergenza

Durante un’emergenza locale, una dorsale in rame è saltata e tre stabilimenti sono rimasti isolati. Ho montato in poche ore una dorsale VPN su link LTE di backup. IPv4 era dietro carrier-grade NAT, i tunnel IPSec non stabilivano. Ho virato su WireGuard nativo in IPv6, pubblicando i peer con indirizzi globali e prefissi delegati dai router 4G.

Gli ostacoli: MTU ridotta a 1420 per via dell’overlay, blocco ICMPv6 su un firewall di frontiera e DNS che restituiva solo record A per un applicativo interno. Risolto così: policy per ICMPv6 essenziali, peering WireGuard su v6, DNS interno con AAAA coerenti e fallback a v4 testato. La rete è tornata operativa con latenza stabile e accessi agli ERP garantiti. La lezione? Se pianifichi IPv6 prima, in emergenza corri meno.

Errori tipici da evitare

Non misurare. Senza metriche v4/v6 separate, brancoli nel buio. Metto sempre dashboard con tempi di handshake TLS e percentuali di successo per stack.

Ignorare i client: macOS, Windows, Android e iOS scelgono in modo diverso quando forzati da captive portal, VPN o policy. Testali tutti se hai BYOD.

Dimenticare i sistemi di stampa, VoIP e IoT: alcuni parlano solo IPv4 o solo link-local v6. Segmenta e usa proxy o gateway applicativi.

In sintesi

La compatibilità tra IPv4 e IPv6 non è magia, è disciplina. Parti da obiettivi chiari: quali servizi devono essere raggiungibili e come li monitori. Abilita dual-stack con policy speculari, consentendo ICMPv6 critici. Verifica DNS A/AAAA e prepara un piano B (NAT64/DNS64 o VPN moderna) per utenti dietro CGNAT. E soprattutto: prova i percorsi reali con gli strumenti degli utenti, non solo con i tuoi. Così ti eviti la maggior parte dei problemi prima che diventino incidenti.