Dans le fichier tspc.conf, au lieu d’affecter votre IP privée à la variable client_v4, y mettre l’IP publique, l’IP de votre passerelle donc. Puis dans le fichier /usr/pkg/share/tspc/template/netbsd.sh, remplacer :

Exec $ifconfig $TSP_TUNNEL_INTERFACE tunnel $TSP_CLIENT_ADDRESS_IPV4 $TSP_SERVER_ADDRESS_IPV4

par

Exec $ifconfig $TSP_TUNNEL_INTERFACE tunnel [ip.privée] $TSP_SERVER_ADDRESS_IPV4

Et laissez tspc faire le reste.

Il semble qu’il y ait un problème de dépendance dans le package kmod-ipv6 de Kamikaze. En effet, ce dernier installe le module sit.ko nécessaire au montage d’un tunnel 6to4, mais pas le module tunnel4.ko dont sit.ko dépend.

On s’execute :

# ipkg install kmod-iptunnel4

On automatise le chargement de sit.ko

# cat > /etc/modules.d/40-sit
sit
^D

Et pour la session courante :

# insmod sit

l’installation du package kmod-iptunnel4 a déjà chargé le module tunnel4.

La methode “officielle” sous linux pour monter ce type de tunnel est d’utiliser la commande ip. Si ce n’est déjà fait, installez le package :

# ipkg install ip

Reste à monter le lien :

root@OpenWrt:~# ip tunnel add tun6to4 mode sit ttl 64 remote 192.88.99.1 local [votre.ipv4.publique]
root@OpenWrt:~# ip link set dev tun6to4 up
root@OpenWrt:~# ip -6 addr add [votre:ipv4:convertie:en:ipv6]/16 dev tun6to4
root@OpenWrt:~# ip -6 route add 2000::/3 via 2002:c058:6301:: dev tun6to4 metric 1

Quelques mots sur cette barbarie. Vous lirez dans les docs officielles que la création du tunnel se fait de cette façon :

# ip tunnel add tun6to4 mode sit ttl [ttlpardéfaut] remote any local [adresseipv4locale]

Bah merci, mais ça marche pas. Heureusement, fosco a mis la main à la pate et a découvert qu’en remplaçant any par l’IP de la gateway 6to4 (elle possède toujours la meme IP), ça fonctionnait tout de suite mieux.

Nota: Voir l’update en fin de ce billet.

Pour obtenir la conversion de votre IPv4 en IPv6, vous pouvez utiliser la commande suivante (directement pompée de la sus-citée doc officielle) :

ipv4="1.2.3.4"; printf "2002:%02x%02x:%02x%02x::1" `echo $ipv4 | tr "." " "`

Enfin, 2002:c058:6301::, gateway par defaut, n’est autre que l’IPv6, toujours la meme également, des passerelles 6to4.

Finalement, grace à tout ça :

root@OpenWrt:~# ping6 -c1 www.6bone.net
PING 6bone.net (2001:5c0:0:2::24): 56 data bytes
64 bytes from 2001:5c0:0:2::24: icmp6_seq=0 ttl=62 time=236.1 ms

--- 6bone.net ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 236.1/236.1/236.1 ms

Il ne vous reste plus qu’à router vos réseaux.

Quelques autres bons tips sont disponibles le Wiki OpenWRT

Update

Voici finalement ma conf, fonctionnelle, qui contredit les infos précédentes :

root@OpenWrt:~# cat /etc/init.d/ipv6.sh
#!/bin/sh

. /etc/functions.sh

IPV4=$(uci get network.wan.ipaddr)
IPV6PREFIX=$(printf "2002:%02x%02x:%02x%02x" `echo $IPV4 | tr "." " "`)

ip tunnel add tun6to4 mode sit ttl 64 remote any local $IPV4
ip link set dev tun6to4 up
ip -6 addr add ${IPV6PREFIX}::1/16 dev tun6to4
ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1

ip -6 addr add ${IPV6PREFIX}:1::1/64 dev br-lan

Il semble que le dysfonctionnement du mot clé any soit lié à la manière d’annoncer la passerelle 6to4. En effet, lorsque j’annonce la route en utilisant la notation ::192.88.99.1, la documentation officielle s’applique parfaitement.