IPv6, je t’aime mais tout le monde s’en fout

Tags:
5 Comments »

Mes premières expériences avec IPv6 datent de 1999. Je me souviens d’une nuit où un habitué du canal de l’époque, bedlam si mes souvenirs sont bons, rejoint #GCU avec un netmask en 3ffe::, le prefixe alloué au 6bone, un réseau de test IPv6 arrêté en 2006.

Obsessif que je suis, je m’étais lancé corps et âme dans l’aventure, raccordé via freenet6 (société aujourd’hui appelée gogo6) et muni de mon O’reilly IPv6 théorie et pratique, aujourd’hui consultable en ligne.

IPv6, c’était pour demain. 2001, Chez ISDnet, nous disposions d’un /28 IPv6 raccordé au 6bone, propre, validé, nous étions prêts. Au plus tard, le grand mouvement était imminent, 2003 tout au plus. Nous rencontrions des boites spécialisées dans la migration et le matos, toutes passionnées, toutes affirmatives: IPv6, c’était pour demain.

Nous sommes en 2013. Je dispose, dans le réseau d’hébergement de ma boite, de deux préfixes IPv6 officiels. Ça fonctionne, rien à dire. 11000 routes dans la table de routage contre 430000 en IPv4 :

Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet6.0            11520      11520          0          0          0          0
inet.0            630509     433341          0          0          0          0

La latence est correcte, les services répondent bien, pas de soucis. En datacenter, dans le coeur de réseau, c’est ni-ckel.

Et finalement, c’est là que le bât blesse: IPv6, ça marche bien dans le cœur de réseau, entre admins qui se tirent la nouille, mais devinez quoi, j’habite pas dans une salle blanche.

Chez moi, je dispose d’une bête ligne Free qui m’octroie gracieusement un mirobolant /64 IPv6 non routable dans mon réseau interne sans passer par de vieilles bidouilles dignes des années 90. Et lorsque j’”active” l’IPv6 sur ma passerelle (comprendre que je re-place une route par défaut IPv6 et que je démarre rtadvd)… ça rame. Tout rame. L’accès aux sites IPv6-ready bien sûr, et parmis eux Google, mais également l’intégralité de n’importe quel bureau moderne qui d’une façon ou d’une autre enchaîne les gethostbyname() ainsi qu’une foule d’autres requêtes vers le réseau Internet IPv6, puisque la priorité, lorsque vous disposez d’une double pile IPv4-IPv6 va en préférence au v6.

Je suis actuellement raccordé au réseau IPv6 via le tunnel broker Hurricane Electric et ce n’est guère mieux, rien de surprenant puisque quand bien même ces derniers disposent d’un réseau de belle facture, il s’agit malgré tout d’un tunnel, muni de ses propres latences, mais qui a ce gros avantage d’être plus souple puisque HE fournit un /48 à ses “abonnés” (l’inscription est gratuite).

“Mais ou veut-il en venir ? Vous demandez-vous peut-être. Et bien la trame est simple, IPv6, malgré tous les efforts d’évangélisation des différents RIR, RIPE en tête, malgré le prosélytisme des administrateurs réseau, malgré la pénurie (l’absence !) d’adresses IPv4 supplémentaires: tout le monde s’en fout. En particulier, nos FAI bien aimés, bien trop occupés à se mettre sur la gueule. Résultat ? IPv6, pour le moment, ce n’est rien de plus qu’un jouet d’admin.

Update: et suite à ce billet, je me permet de copier ici la réponse d’Octave, monsieur OVH, qui a le mérite d’être clair: @iMilnb rien qu’en France chaque FAI a un stock d’IPv4 qui lui permet de doubler le nombre d’abonnés. IPv6 ? on se détend, c’est l’apéro ;)

Une bien belle conclusion. IPv6, c’est pas pour demain.

Routage IPv6 via freebox

Tags: , ,
No Comments »

J’enquille donc sur le précédent post sur le sujet avec cette fois une configuration qui sied à une passerelle de type GNU/Linux calée en bridge derrière une freebox, voir deux billets plus bas pour l’explication de fond, nous irons à l’essentiel ici.
Dans cet exemple, eth0 représente l’interface raccordée à notre réseau privé, et eth1 celle raccordée à la freebox:

  • É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.

Transformer 6

Tags: ,
No Comments »

Sans vraiment y croire, je vais sur test-ipv6 avec ma tablette sous Android (une Asus Transformer), et quelle ne fut pas ma surprise de constater:

Transformer IPv6

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.

Routage IPv6 sur une passerelle chez OVH (et probablement Free)

Tags: , , ,
2 Comments »

Free et OVH proposent tous deux une connectivité IPv6 depuis un certain temps. Les deux ont ceci de commun que sur le papier, ils fournissent un prefixe /64, il se trouve qu’OVH fournit en réalité un /56, mais cela a peu d’intérêt pour l’astuce qui va suivre.

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.

Comment chu trop un sage

Tags:
1 Comment »

Voila un week end BIEN productif ! Comme je ne m’étais pas replongé dans IPv6 depuis la glorieuse époque isdnet, je me suis dit qu’il était grand temps de me rafraîchir la mémoire; j’ai donc été au bout de la certification IPv6 de HE qui va de la simple déclaration d’un tunnel v4/v6 à l’enregistrement d’une zone DNS IPv6 parfaitement fonctionnelle en passant par un MX et un desktop double pile aux petits oignons. Et ça fait du bien !
Compte tenu de la situation, je ne saurais trop vous encourager à faire de même, et de ramener ce savoir dans vos boulots, c’est pas comme si le grand mouvement avait lieu demain, mais compte tenu de l’ampleur de la tâche, il est pas trop tot…
Allez, jme la pête au laser: .

mmmmm les bons spaghettis

Tags: , , , , ,
1 Comment »

Ça commence à sentir le vieux sac de lacets sur ma routing box.
Pour rappel, j’utilise un domU NetBSD hébergé quelque part pour différencier mon traffic sortant. Ce domU est controllé par un dom0 Debian Squeeze, et a ceci de particulier que sa route par défaut part vers la suède. Seuls quelques services répondent directement sur l’IP publique “réelle”, sur laquelle j’opère du SNAT et du DNAT.

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 !

WP Theme & Icons based on GlossyBlue by N.Design Studio
Banner from www.trynthlas.com
Entries RSS Comments RSS Log in
Optimization WordPress Plugins & Solutions by W3 EDGE