NB — In corsivo, le impostazioni per la navigazione anonima. In grassetto, le impostazioni per la navigazione tramite account.

Entro nel dettaglio: il valore della variabile client_v4 dev’essere cambiato (utilizzando un IP del tipo 0.0.0.0) esclusivamente in presenza di un IP pubblico statico — già fornito dall’ISP, a seconda dell’abbonamento sottoscritto.

Per ciò che concerne tunnel_mode, invece, ho personalmente optato per il valore v6udpv4 perché sono a conoscenza del NAT: di conseguenza, ho commentato la variabile if_tunnel_v6v4, poiché certo che il tunnel non possa assumere quel valore. In tutti gli altri casi, è consigliabile mantenere attivi entrambi.

È evidente che, per sfruttare la modalità NAT, sia necessario installare il modulo del kernel relativo al driver TUN/TAP: il problema più comune degli utenti “entry-level“ è, appunto, l’assenza di questo. Con Ubuntu non c’è bisogno di ricompilare il kernel: basta aggiungere il modulo tun e fare in modo che sia caricato in avvio.

$ sudo modprobe tun
$ sudo echo tun >> /etc/modules

Le 3 variabili host_type, prefixlen e if_prefix sono direttamente collegate: anzitutto, difficilmente esiste la necessità di modificare prefixlen con un valore di 48 (riservato alle reti fisiche o, virtuali con più di una subnet mask); la tipologia di host e il “prefisso” – ovvero, il nome dell’interfaccia di rete principale – dipendono essenzialmente dalla configurazione di /etc/network/interfaces. In presenza di un bridge, infatti, if_prefix dev’essere settato sull’interfaccia principale (nel mio caso, br0, che determina l’IP locale del network): se non c’è una simile necessità, si può tranquillamente impostare host.

Qualora non s’intenda procedere con la configurazione di radvd (che, nel qual caso, non andrebbe neppure installato), è possibile procedere al riavvio della rete e del client:

$ sudo /etc/init.d/tspc restart
$ sudo /etc/init.d/networking restart

Quindi, verificare la corretta assegnazione dell’IP e il funzionamento del protocollo: attenzione, perché devono essere presenti 2 voci inet6 addr (la prima, infatti, è impostata di default a uso interno).

$ ifconfig
$ ping6 ipv6.google.com

Per motivi che mi sono tuttora ignoti, è possibile che il ping sia effettuato con successo, mentre il browser e/o altre applicazioni non riescano ad accedere all’IPv6 — soprattutto quando la connessione all’ISP dovesse essere reimpostata.

Arrivando a radvd, si consideri che il demone non ha una configurazione predefinita: la via più immediata per assegnargliene una è quella di copiare in /etc uno dei file d’esempio provvisti.

$ sudo cp /usr/share/doc/radvd/examples/radvd.conf.example /etc/radvd.conf

Occorre verificare che interface corrisponda al valore impostato per if_prefix: personalmente, mi limito a commentare le stringhe relative a RDNSS — che è ancora in stato di draft.

# RDNSS 2001:db8::1 2001:db8::2 {
# AdvRDNSSPreference 8;
# AdvRDNSSOpen off;
# AdvRDNSSLifetime 30;
# };

C’è bisogno, prima di avviare il demone, di modificare il template di tspc: poiché radvd assegna indirizzi con prefisso 2001 (anziché 2000, come previsto da linux.sh), è necessario modificare le stringhe relative al riavvio della connessione… per scongiurare che quest’ultimo impedisca l’assegnazione di un IP.

$ sudo gedit /etc/tsp/linux.sh

ExecNoCheck $route -A inet6 del 2001::/3 2>/dev/null
Exec $route -A inet6 add 2001::/3 dev $TSP_TUNNEL_INTERFACE

NB — In corsivo, le modifiche all’originale.

Ora, è finalmente possibile avviare il demone e – di conseguenza – completare l’intero processo:

$ sudo /etc/init.d/radvd start

Nel caso dell’impossibilità recidiva di configurare il tunnel IPv6, è possibile consultare il file /etc/sysctl.conf e verificare che sia de-commentata la stringa: net.ipv6.conf.all.forwarding=1.