Come risolvere IPv6 senza rete o accesso a Internet

IPv6 che si accende ma non naviga: il punto non è “IPv6 sì o no”, è dove si rompe il percorso

Quando un host mostra un indirizzo IPv6 ma non raggiunge Internet, il problema raramente è “IPv6 rotto” in senso generico. Quasi sempre c’è un anello spezzato lungo la catena: prefisso non annunciato, gateway assente, router advertisement incoerenti, DNS che risponde solo in v4, firewall che lascia passare il ping ma blocca il traffico utile, oppure un upstream che non sta davvero instradando il prefisso assegnato.

La regola pratica è semplice: non partire dal browser. Parti dal layer di rete, verifica se l’host ha un indirizzo globale, se vede un router di default, se riesce a raggiungere il gateway link-local e se il problema è di connettività pura o di risoluzione nomi. Se mescoli tutto, perdi tempo e finisci a fare prove casuali.

Prima distinzione: IPv6 assente, IPv6 presente ma isolato, IPv6 presente ma DNS sbagliato

Tre scenari diversi, tre diagnosi diverse.

• IPv6 assente: l’interfaccia ha solo link-local fe80::/10 oppure nessun indirizzo v6 globale.
• IPv6 presente ma isolato: l’host ha un indirizzo globale, ma non riesce a fare routing verso l’esterno.
• IPv6 presente ma DNS sbagliato: la connettività v6 funziona, ma i nomi non si risolvono o risolvono record errati.

Questa distinzione evita il classico errore: cambiare DNS quando in realtà manca il default route, oppure inseguire il firewall quando il prefisso non è mai stato annunciato.

Controlli minimi sul nodo: indirizzo, route, neighbor, DNS

Su Linux recente, il primo giro di verifica è corto e molto informativo.

ip -6 addr show dev eth0
ip -6 route show
ip -6 neigh show
resolvectl status

Se non usi systemd-resolved, il comando equivalente è leggere /etc/resolv.conf e capire se i resolver sono coerenti con la rete in uso. L’obiettivo è vedere quattro cose:

1. un indirizzo globale o ULA coerente con il contesto;
2. una route default via fe80::... o una route verso il prefisso upstream;
3. neighbor discovery funzionante verso il gateway;
4. DNS che non punta a resolver inaccessibili via IPv6.

Se manca il default route, la macchina può “avere IPv6” ma non uscire. Se il neighbor table è vuoto o in stato FAILED, il problema è quasi sempre sul link locale, sul router advertisement o sul gateway stesso. Se il resolver è raggiungibile solo via IPv6 e l’IPv6 è già rotto, hai creato un circolo vizioso inutile.

Router Advertisement: il punto più spesso ignorato

In ambienti con SLAAC o configurazione ibrida, i router advertisement sono il cuore del meccanismo. Se l’host riceve RA incoerenti, puoi vedere sintomi strani: indirizzo assegnato ma nessun default route, lifetime scaduta, prefisso presente ma gateway non utilizzabile, oppure metriche di route che fanno preferire un percorso sbagliato.

Per controllare se il nodo vede davvero gli annunci, usa:

sudo tcpdump -i eth0 -n icmp6 and ip6[40] == 134

Se non vedi RA, il problema è a monte: il router non li manda, il bridge non li passa, il firewall li filtra, oppure il server è su una VLAN che non riceve gli annunci previsti. Se li vedi ma il nodo non installa il default route, controlla la configurazione del client: su alcune distro, un demone di rete può ignorare RA se la policy è stata irrigidita.

Un dettaglio che torna spesso in produzione: il router manda RA ma con lifetime troppo breve o prefisso già scaduto. Il sistema resta apparentemente connesso per pochi minuti e poi cade. Qui il sintomo tipico è una perdita intermittente, non un down netto.

Quando il prefisso c’è ma Internet no: upstream, routing e firewall

Se l’host ha indirizzo e default route, il test successivo è capire se il traffico esce davvero dal confine di rete. La verifica più economica è un traceroute v6 e un ping verso un target noto, meglio se un indirizzo IPv6 pubblico stabile.

ping -6 -c 3 2001:4860:4860::8888
traceroute -6 2001:4860:4860::8888

Se il primo hop risponde e poi tutto si ferma, il problema è oltre il gateway locale: routing upstream, filtraggio, NAT66 se presente, o policy dell’operatore. Se non risponde nemmeno il primo hop, il guasto è quasi certamente sul tratto link-local o sul router di default.

In reti aziendali e hosting, una causa ricorrente è il prefisso assegnato ma non effettivamente instradato dall’upstream. Succede dopo un cambio di router, una migrazione di rack o una modifica al peering. La macchina ha un indirizzo valido, ma il mondo esterno non sa come tornare indietro. In pratica, il traffico esce, le risposte non rientrano.

Un’altra variante è il firewall che consente ICMPv6 minimale ma blocca il resto. Con IPv6 non puoi trattare ICMP come traffico “di contorno”: Neighbor Discovery, Packet Too Big e alcuni messaggi di controllo sono parte del funzionamento. Se li blocchi, rompi la rete in modo meno evidente del solito.

DNS: il falso colpevole quando IPv6 funziona a metà

Molti casi di “IPv6 non va” sono in realtà DNS. Il client risolve solo A, oppure riceve AAAA ma il resolver è raggiungibile solo via v4, oppure il resolver risponde ma l’applicazione preferisce male il family selection e va in timeout su IPv6 prima di ripiegare sul v4.

Verifica con:

dig AAAA example.com
resolvectl query example.com
curl -6 -I https://example.com

Se dig AAAA restituisce record validi ma curl -6 fallisce, la rete IPv6 del nodo è il problema. Se curl -6 funziona ma il browser no, controlla policy applicative, proxy, browser stack e DNS locale. Se il resolver stesso è irraggiungibile via v6, hai una dipendenza circolare: il sistema prova a usare DNS su una rete che non è ancora sana.

In ambienti con split DNS, il problema si complica: il nome interno risolve in IPv6 solo da una certa VLAN o da un certo resolver, mentre l’host sta usando un resolver sbagliato. Qui non serve “riavviare la rete”: serve capire quale resolver è attivo e da dove arriva la configurazione.

MTU e PMTUD: il guasto invisibile che sembra un problema di accesso

IPv6 è più sensibile ai problemi di MTU di quanto molti ricordino. Se un path ha MTU inferiore e i messaggi Packet Too Big vengono filtrati, alcune connessioni sembrano aprirsi e poi si fermano. Tipico caso: ping piccolo ok, HTTPS o SSH appesi, download che partono e poi muoiono.

Un test semplice è provare pacchetti con dimensioni crescenti:

ping -6 -M do -s 1200 2001:4860:4860::8888
ping -6 -M do -s 1400 2001:4860:4860::8888

Se un valore funziona e uno no, il path MTU è un indizio forte. Se la rete intermedia blocca ICMPv6, il problema non si vede subito ma si manifesta su applicazioni reali. La correzione non è “alzare il timeout”: è permettere i messaggi ICMPv6 necessari e allineare MTU e policy lungo il percorso.

Firewall locale e sysctl: quando l’host si difende troppo bene

Un firewall host-based può bloccare traffico in uscita o in entrata in modo selettivo. Su IPv6, il rischio è doppio: regole ereditate da IPv4 copiate male, oppure policy troppo aggressive su ICMPv6.

Controlli utili:

nft list ruleset
ip6tables -S
sysctl net.ipv6.conf.all.disable_ipv6
sysctl net.ipv6.conf.all.accept_ra

Se IPv6 è disabilitato via sysctl, l’host può sembrare configurato ma non lo è davvero. Se accept_ra è spento su una macchina che dipende da SLAAC, il default route non arriverà mai. Se il firewall filtra ICMPv6 in modo grossolano, stai rompendo il meccanismo base di discovery.

In ambienti server, vale una regola pratica: non bloccare ICMPv6 senza sapere esattamente quali tipi stai lasciando passare. Il costo di una policy sbagliata su IPv6 è spesso molto più alto del risparmio apparente in superficie d’attacco.

Server, hypervisor e bridge: il guasto che nasce sotto l’ospite

Se l’host è una VM, il punto da verificare non è solo il sistema operativo guest. Il problema può stare nel bridge del nodo, nel virtual switch, nel security group del cloud o nel router virtuale del provider.

Molti casi “IPv6 non naviga” in cloud derivano da una di queste situazioni:

• prefisso assegnato ma non associato alla NIC corretta;
• security group che consente TCP ma non ICMPv6;
• route table del VPC/VNet non aggiornata;
• RA o DHCPv6 bloccati dal layer virtuale;
• IPv6 abilitato nel pannello ma non realmente attivo sulla subnet.

Qui il percorso giusto è quasi sempre doppio: controlli sul guest e controlli sul pannello del provider. Se hai accesso al pannello, verifica che il prefisso sia allocato alla subnet giusta, che il gateway sia quello previsto e che la policy firewall non stia filtrando il traffico di controllo.

Sequenza di troubleshooting che non fa perdere tempo

Se devi isolare il problema in meno di dieci minuti, usa questa sequenza.

1. Verifica se l’host ha un indirizzo IPv6 globale con ip -6 addr.
2. Verifica il default route con ip -6 route.
3. Ping del gateway link-local o del primo hop noto.
4. Test verso un indirizzo pubblico IPv6 con ping -6 e curl -6 -I.
5. Controllo DNS con dig AAAA o resolvectl query.
6. Se necessario, cattura RA e Neighbor Discovery con tcpdump.

Questa sequenza separa quasi sempre il problema in una delle tre famiglie: configurazione locale, rete L2/L3, o upstream esterno. L’errore classico è invertire i passi e finire a cambiare DNS quando il gateway non esiste.

Correzioni pratiche: cosa cambiare, in che ordine, e con quale rischio

Se stai intervenendo in produzione, la priorità è la modifica minima reversibile. Non rifare la rete da zero se basta ripristinare un route o correggere un RA.

1. Se manca il default route: correggi il router advertisement o la configurazione DHCPv6/SLAAC. Prima fai backup della config del demone di rete o del router. Verifica subito con ip -6 route.
2. Se il DNS rompe la navigazione: allinea i resolver, preferisci quelli raggiungibili via rete funzionante e verifica resolvectl status o il file di configurazione del resolver. Evita di puntare tutto a un resolver che risponde solo in IPv6 se IPv6 è instabile.
3. Se il firewall blocca ICMPv6: aggiungi eccezioni mirate per Neighbor Discovery, Packet Too Big e RA dove serve. Fai un backup del ruleset prima di applicare il diff.
4. Se il prefisso non torna dall’upstream: apri il cambio lato router/provider. Qui la correzione locale non basta; serve verificare l’annuncio del prefisso e la route di ritorno.
5. Se il problema è MTU: ripristina un path coerente o consenti i messaggi di controllo. Non usare workaround permanenti che mascherano il guasto.

Ogni correzione va verificata con un test funzionale, non solo con lo stato del servizio. Ad esempio: curl -6 -I https://example.com per HTTP, ping -6 per reachability, dig AAAA per DNS, e un traceroute se il guasto è di routing.

Osservabilità minima: cosa tenere sotto mano mentre sistemi

Per non lavorare al buio, tieni aperti almeno questi segnali:

• error rate delle richieste IPv6 vs IPv4;
• latenza p95 su connessioni IPv6;
• numero di neighbor in stato FAILED o STALE anomalo;
• presenza e durata del default route;
• log del demone di rete e del firewall;
• eventuali reset o timeout osservati a livello applicativo.

Se il sistema ha metriche separate per family, confrontale. Il vantaggio di IPv6 è anche questo: puoi vedere chiaramente se il problema è specifico della nuova pila o se è un difetto generale mascherato dal fallback in IPv4.

Un caso tipico: indirizzo presente, ping al gateway ok, siti no

Questo scenario è comune e inganna parecchio. Il nodo raggiunge il gateway, ma non Internet. Le cause più probabili sono due: upstream che non instrada il prefisso o firewall intermedio che blocca il traffico in uscita dopo il primo hop. Se il ping al gateway funziona e il traceroute si ferma lì, il problema è oltre l’host. Se invece il traceroute mostra hop successivi ma le richieste HTTPS falliscono, sospetta MTU o filtri su ICMPv6.

In un ambiente hosting, la risposta corretta non è riavviare il server. È verificare il routing del prefisso sul router, confermare che il firewall permetta ICMPv6 essenziale e controllare che il resolver non stia dipendendo da un percorso già guasto.

Quando conviene disattivare IPv6 temporaneamente

Solo come mitigazione e solo se hai un impatto utenti serio che non riesci a chiudere rapidamente. Disattivare IPv6 può ridurre il danno, ma introduce un cambiamento di comportamento che va trattato come rollback temporaneo, non come soluzione.

Se fai questa scelta, documenta il motivo, limita il raggio d’azione al nodo o al servizio coinvolto e prepara il ripristino. Il rischio è semplice: spegni la famiglia che mostra il guasto e nascondi il difetto reale, che poi riemerge al prossimo cambio di rete.

Meglio usare IPv6 in modo disciplinato: osservare, isolare il layer, correggere il punto minimo e verificare con un test che tocchi davvero il percorso di rete. È il modo più rapido per uscire dal falso dilemma “IPv6 funziona o non funziona”. La domanda giusta è sempre: dove si rompe?

Checklist finale da usare prima di chiudere il ticket

Prima di considerare risolto il problema, verifica almeno questi punti:

1. ip -6 addr mostra un indirizzo coerente con la subnet attesa.
2. ip -6 route include un default route valido.
3. ping -6 verso gateway e target pubblico ha esito positivo.
4. curl -6 -I verso un sito noto restituisce risposta corretta.
5. dig AAAA o resolvectl query restituisce record coerenti.
6. Firewall e security group non bloccano ICMPv6 necessario.
7. Se c’era un cambio config, hai un backup o un diff reversibile.

Assunzione: l’ambiente è Linux recente con rete gestita da systemd o tool equivalenti, e il problema riguarda una connessione IPv6 che dovrebbe essere operativa ma non lo è.

IPv6 non si diagnostica “per tentativi”. Si isola il layer, si guarda l’evidenza minima e si cambia il minimo indispensabile.