• Évidemment, il faudra activer le mode IPv6 sur votre interface free
• On place les sysctl adéquats:

  net.ipv6.conf.all.forwarding=1
  net.ipv6.conf.all.proxy_ndp=1
  # pas d'autoconfiguration pour la passerelle
  net.ipv6.conf.all.autoconf=0
  net.ipv6.conf.all.accept_ra=0

• On renseigne son IPv6, par exemple pour le sous-réseau 2a01:e35:39d7:e3e0::/64:

  ip -6 addr add 2a01:e35:39d7:e3e0::2/64 dev eth1

• On déclare sa passerelle:

  ip route add default via 2a01:e35:39d7:e3e0::1 dev eth1

• Puis on place une IPv6 qui servira de passerelle à notre réseau privé sur eth0 avec une longueur de préfixe juste suffisante:

  ip -6 addr add 2a01:e35:39d7:e3e0:1::1/126 dev eth0

• L’astuce, ici encore, consiste à proxyiser les adresses du LAN sur l’interface raccordée à la freebox afin d’apparaître comme un réseau “à plat”:

  ip neigh add proxy 2a01:e35:39d7:e3e0:1::1 dev eth1

• Il suffit alors de faire de même pour toute machine de votre LAN que vous souhaitez raccorder à l’IPv6, par exemple, toujours sur la passerelle:

  ip neigh add proxy 2a01:e35:39d7:e3e0:1::2 dev eth1

• Sur la machine qui portera l’adresse 2a01:e35:39d7:e3e0:1::2, on ajoute à l’interface son IPv6, et on déclare comme passerelle par défaut 2a01:e35:39d7:e3e0:1::1:

  ip -6 addr add 2a01:e35:39d7:e3e0:1::2/126 dev eth0
  ip route add default via 2a01:e35:39d7:e3e0:1::1

• Il conviendra de rajouter tout ce petit monde dans votre /etc/network/interfaces comme il se doit, encore une fois je vous renvoie 2 posts plus bas.

La méthode est fastidieuse et pas forcément élégante, mais tant que l’opérateur free ne se sera pas sorti les ne routera pas plus qu’un /64 dans les foyers, nous devrons nous contenter de cela… ou passer la freebox en mode routeur. Nan j’déconne.

Pas d’étonnement, mon HTC Desire HD sous Android montre le même résultat:

Et histoire de me gausser, je fais le même test avec l’iPoo du boulot… bah pareil:

Ça commence à sentir bon !

Je précise qu’évidemment, ces tests ont été menés en mode WiFi et non en passant par l’opérateur de téléphonie.

Les routeurs des deux sociétés s’attendent donc à recevoir du flux IPv6 depuis un réseau “plat”, et ceci pose un réel soucis lorsque vous souhaitez distribuer une connectivité IPv6 à votre réseau possiblement NATté derrière votre passerelle. Plusieurs astuces sont disponibles depuis belle lurette, parmi elles l’utilisation d’un bridge associé à une règle ebtables, mais aussi et surtout la mise en place du proxying NDP. Je me suis basé sur cette dernière méthode, que j’ai adapté à mon éternel setup: dom0 debian GNU/Linux et domU NetBSD.

La procédure est la suivante:

On active en premier lieu le mode proxy NDP ainsi que le forwarding IPv6 sur notre dom0:

sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv6.conf.all.proxy_ndp=1

Il conviendra evidemment de rendre cette configuration permanente en ajoutant ces valeurs dans le fichier /etc/sysctl.conf
Puis, sur notre interface de bridging Xen, nous ajoutons l’IPv6 dans le sous-réseau fourni par le fournisseur, cette adresse sera l’IP passerelle pour nos domUs:

# ifconfig xenbr0 inet6 add 2001:41e8:1:fe10::1/64

Toute l’astuce consiste à proxyiser l’adresse MAC de l’interface xenbr0 sur l’interface physique de la machine que voit réellement le fournisseur à l’aide de la commande ip:

ip neigh add proxy 2001:41e8:1:fe10::1 dev eth0

Il convient évidemment d’ajouter une route par défaut pour les adresses IPv6, cette dernière vous est fournie par votre fournisseur, par exemple pour OVH:

route -A inet6 add default gw 2001:41e8:1:feff:ff:ff:ff:ff

Nous attribuerons à notre domU l’IPv6 2001:41e8:1:fe10::2, ainsi, nous proxyisons également cette dernière de cette façon:

ip neigh add proxy 2001:41e8:1:fe10::2 dev eth0

Enfin, sur notre domU, nous ajoutons cette IP à l’interface raccordée au bridge ainsi qu’une route par défaut pointant vers l’IP de ce dernier:

ifconfig xennet0 inet6 2001:41e8:1:fe10::2 prefixlen 64
route -n add -inet6 default 2001:41e8:1:fe10::1

Et rendons ces paramètres permanents en ajoutant dans le fichier /etc/ifconfig.xennet0:

inet6 2001:41e8:1:fe10::2 prefixlen 64
!route -n add -inet6 default 2001:41e8:1:fe10::1

Finalement, nous inscrivons dans le fichier /etc/network/interfaces de notre dom0:

iface xenbr0 inet6 static
	2001:41e8:1:fe10::1
	netmask 64
	gateway 2001:41e8:1:feff:ff:ff:ff:ff
	# NDP / ARP proxying for xenbr0
	up ip neigh add proxy 2001:41e8:1:fe10::1 dev eth0
	down ip neigh del proxy 2001:41e8:1:fe10::1 dev eth0
	# NDP / ARP proxying for domU 1
	up ip neigh add proxy 2001:41e8:1:fe10::2 dev eth0
	down ip neigh del proxy 2001:41e8:1:fe10::2 dev eth0

Et le tour est joué.

Notez que je n’ai pas eu besoin, au contraire de ce qu’indique la documentation sur laquelle je me suis appuyé, de passer l’interface eth0 en mode promiscuous, probablement parce que j’utilise un bridge monté sur une interface de type dummy, dissocié de l’interface physique, et que les routes IPv6 de mes domU utilisent explicitement l’IP montée sur ce dernier.

Tout ceci manquait cruellement d’un soupçon d’IPv6. Ainsi, après m’être frotté à SixXs et son système de crédits aussi ingénieux que pénible, j’ai finalement opté pour Hurricane Electric qui a en plus le bon goût de posséder un endpoint à Paris.

Si la configuration d’un tunnel v4/v6 se réalise le plus simplement du monde depuis plus de 10 ans via des tunnels gif, l’opération n’est pas complètement triviale lorsque le endpoint se trouve être NATté et qu’en plus ce dernier utilise une route par défaut différente de l’IP publique officielle du dom0.

Ainsi, après avoir souscrit à un endpoint IPv6 chez HE, quelques opérations sont nécessaires au bon fonctionnement du routage. Nous considèrerons que l’ip du endpoint gif IPv4 chez Hurricane est 1.2.3.4 et que notre IPv4 publique, sur le dom0 donc, est 5.6.7.8.

La première chose à faire sur notre dom0 est de rediriger tout le traffic en provenance de HE vers notre domU, dont nous considèrerons que l’IPv4 privée est 192.168.0.1.

# iptables -t nat -A PREROUTING -i eth0 -s 1.2.3.4 -j DNAT --to-destination 192.168.0.1

Il faudra évidemment, si cela n’est pas déjà fait, appliquer du SNAT afin que votre domU puisse “sortir” et se présenter avec notre IPv4 publique au monde. Par exemple:

# iptables -t nat -A POSTROUTING -s 192.168.0.1/32 -o eth0 -j SNAT --to-source 5.6.7.8

C’est l’unique configuration à effectuer sur le dom0. Jusqu’ici tout va bien.

Sur notre domU NetBSD, nous créons l’interface de tunneling comme ceci:

# ifconfig gif0 create
# ifconfig gif0 tunnel 192.168.0.1 1.2.3.4
# ifconfig gif0 inet6 2001:470:1e31:b2c::2 2001:470:1e31:b2c::1 prefixlen 128

Notez que c’est bien l’IPv4 privée que nous utilisons pour monter le tunnel gif, le SNAT du dom0 s’occuppera de transformer cette IP au vol.
Cette seule configuration, compte tenu du routage particulier de notre domU, ne suffira pas au bon fonctionnement du tunnel. Deux opérations sont nécessaires:

• Ajouter une route explicite vers le endpoint HE
• Forcer la sortie vers l’interface réelle du dom0 lorsqu’on essaye de joindre une adresse IPv6

Execution:

# route add -host 1.2.3.4 192.168.0.254

Ici, 192.168.0.254 est l’adresse passerelle du dom0.

# grep he_tunnel /etc/pf.conf-ovpn
he_tunnel="1.2.3.4/32"
pass out quick route-to ($real_if $gateway) from any to $he_tunnel

$real_if représente l’interface xennet0, et $gateway l’adresse de notre passerelle coté dom0, à savoir 192.168.0.254.
Reste à appliquer une route par défaut pour les adresses IPv6:

route -n add -inet6 default 2001:470:1e31:b2c::1

Et nous y sommes. Enfin, il faut evidemment automatiser toutes ces manipulations afin de retrouver notre état fonctionnel à chaque reboot, cela est réalisé en créant le fichier /etc/ifconfig.gif0 avec ce contenu:

create
tunnel 192.168.0.1 1.2.3.4
inet6 2001:470:1e31:b2c::2 2001:470:1e31:b2c::1 prefixlen 128
!route add -host 1.2.3.4 192.168.0.254
!route -n add -inet6 default 2001:470:1e31:b2c::1

And voila, Danse petite tortue, danse !

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.