Transizione a IPv6: come gli ISP gestiscono dual-stack, DS-Lite e NAT64

Lo spazio IPv4 pubblico è esaurito: RIPE NCC ha terminato l'allocazione libera nel novembre 2019 e da allora un nuovo operatore può ottenere al massimo un /24 dalla waiting list. IPv6 non è più un esercizio accademico ma un requisito operativo, e il problema per un ISP non è "accendere IPv6" — è farlo convivere con un Internet che per una parte rilevante parla ancora solo IPv4.

Perché non basta "attivare IPv6"

Attivare IPv6 sui router di edge è la parte facile. Il vincolo reale è che il cliente deve continuare a raggiungere servizi IPv4-only, e molti servizi IPv4-only non hanno alcun piano di migrazione. Qualsiasi strategia di transizione deve quindi rispondere a due domande:

• Come raggiunge il cliente le destinazioni IPv4? Con un indirizzo IPv4 dedicato, condiviso, o tradotto?
• Dove sta la complessità? Nel CPE del cliente o in un box centralizzato dell'operatore?

Le tre famiglie di soluzioni che seguono rispondono in modo diverso a queste domande.

Dual-stack: la soluzione pulita

Nel dual-stack il cliente riceve contemporaneamente un indirizzo IPv4 (pubblico o CGNAT) e un prefisso IPv6, tipicamente un /56 o un /64 delegato via DHCPv6-PD. Le due pile viaggiano in parallelo e indipendenti: il dispositivo risolve un nome, ottiene record A e AAAA, e sceglie.

La selezione non è casuale. Il meccanismo Happy Eyeballs (RFC 8305) fa partire i tentativi di connessione su entrambe le famiglie con un piccolo ritardo a favore di IPv6, e usa la prima che risponde. Il risultato è che una rete IPv6 lenta o mal configurata non degrada l'esperienza in modo visibile — il che è comodo, ma rende anche più difficile accorgersi che IPv6 è rotto.

Vantaggi e limiti:

• Nessuna traduzione nel percorso IPv6, quindi zero overhead e nessun single point of failure.
• Il traffico IPv4 continua a consumare indirizzi: se sono in CGNAT, tutti i problemi noti del CGNAT restano.
• Serve gestire e monitorare due piani di indirizzamento, due set di ACL, due tabelle di routing.

Per un ISP che ha ancora IPv4 sufficienti — anche assegnati via CGNAT — il dual-stack è la scelta di default e la più semplice da diagnosticare.

DS-Lite: IPv6 nativo, IPv4 incapsulato

Con Dual-Stack Lite (RFC 6333) la rete di accesso è solo IPv6. Il CPE del cliente, chiamato B4, incapsula il traffico IPv4 in pacchetti IPv6 (softwire IPv4-in-IPv6) e lo manda a un concentratore dell'operatore, l'AFTR, che decapsula ed effettua il NAT verso Internet.

Il cliente in LAN usa indirizzi privati normali; l'unico IPv4 pubblico è quello dell'AFTR, condiviso tra molti utenti. Punti di attenzione:

• MTU: l'header IPv6 aggiunge 40 byte. Senza un aggiustamento (MSS clamping a 1420 o meno, o MTU maggiorata sul core) si ottengono i classici sintomi da PMTU rotto — la pagina si apre ma il download si blocca.
• Nessun port forwarding: come nel CGNAT, il NAT è nell'AFTR e il cliente non lo controlla. PCP (RFC 6887) può ovviare, ma richiede supporto lato operatore e lato CPE.
• Capacità centralizzata: l'AFTR è un punto di concentrazione e va dimensionato in sessioni NAT, non solo in banda.

NAT64 e 464XLAT: rete IPv6-only

NAT64 (RFC 6146) accoppiato a DNS64 permette a un host che ha solo IPv6 di parlare con un server IPv4-only. Il resolver DNS64, quando non trova un record AAAA, ne sintetizza uno inserendo l'indirizzo IPv4 dentro un prefisso dedicato — di solito il well-known 64:ff9b::/96. Il traffico verso quel prefisso finisce sul traduttore NAT64, che ricostruisce il pacchetto IPv4.

Il limite è noto: le applicazioni che usano indirizzi IPv4 in forma letterale, senza passare dal DNS, non funzionano. È il motivo per cui esiste 464XLAT (RFC 6877), lo schema adottato in massa dagli operatori mobili: il dispositivo esegue una traduzione stateless da IPv4 a IPv6 (CLAT) e l'operatore la traduzione stateful inversa (PLAT). Android lo implementa nativamente, iOS lo gestisce a livello di sistema; su reti fisse va implementato nel CPE.

Cosa guardare in fase di rollout

Alcuni controlli che fanno la differenza tra un IPv6 "acceso" e un IPv6 funzionante:

• Delegare un /56, non un /64. Un solo /64 impedisce al cliente di segmentare la LAN in VLAN o subnet multiple. Il /56 è la raccomandazione RIPE-690.
• Prefissi stabili. Un prefisso che cambia ad ogni riconnessione rompe firewall rule, DNS interni e reverse proxy. Se il prefisso deve essere dinamico, va detto chiaramente.
• PMTUD e ICMPv6. In IPv6 non esiste la frammentazione da parte dei router: filtrare ICMPv6 Packet Too Big significa rompere le connessioni in modo silenzioso e intermittente.
• Firewall di default in ingresso. Con IPv6 ogni host ha un indirizzo raggiungibile: il CPE deve avere una policy stateful di default-deny in entrata, altrimenti si espone la LAN.
• Reverse DNS e RPKI. Il PTR sui prefissi IPv6 conta per la reputazione mail; le ROA vanno pubblicate anche per gli annunci IPv6.

Verificare da casa

Due comandi bastano per capire se IPv6 è realmente attivo e funzionante:

• ping -6 ipv6.google.com — verifica connettività di base e risoluzione AAAA.
• traceroute -6 verso una destinazione nota — mostra se il traffico esce dall'AS dell'operatore o si ferma al primo hop.

Se il ping IPv6 funziona ma il traffico reale è tutto IPv4, il problema è quasi sempre nel DNS del CPE o in una policy di address selection sul client. Il sito test-ipv6.com resta il modo più rapido per un check complessivo, con il punteggio che indica sia la raggiungibilità sia la presenza di problemi di MTU.