[ipv6] Routage IPv6

[burban at fdn.fr]

Laurent GUERBY <laurent at guerby.net> writes:

> On Fri, 2011-09-23 at 01:54 +0200, burban at fdn.fr wrote:
>> Laurent GUERBY <laurent at guerby.net> writes:
>> 
>> > Bonjour,
>> >
>> > J'ai crée une page wiki pour qu'on puisse noter les
>> > informations :
>> >
>> > http://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/IPv6
>> >
>> > Le stage sur la sécurité IPv6 via ip6table n'a pas abouti
>> > le ticket est toujours la avec quelques liens utiles :
>> >
>> > http://chiliproject.tetaneutral.net/issues/35
>> >
>> > Actuellement tetaneutral.net livre un /56 avec le gateway en link-local
>> > (fe80::31), ça marche sur les VM, machines et pour les certificats
>> > openvpn tap. 
>> >
>> > Par contre je ne sais pas si un utilisateur peut vraiment router des
>> > sous reseaux facilement par opposition a ajouter des hosts, quelqu'un a
>> > une idée ? Peut-etre faut-il proposer une option pour router le traffic
>> 
>> J'ai fait quelques essais: VM configuré en routeur, openvpn entre la VM
>> et ma machine, histoire de simuler des interfaces. J'ai essayé radvd
>> comme des définitions manuelles des adresses IPv6.
>> 
>> Bon, ça marche depuis la VM mais pas depuis chez moi (wget
>> http://ipv6.google.com), même si les paquets IPv6 (vu avec tcpdump)
>> partent bien de la VM vers l'internet. Mais il n'y a pas de retour.
>> 
>> Après quelques cogitations et la lecture de ceci:
>> http://www.fdn.fr/IPv6-a-la-maison.html j'en arrive à ces
>> réflexions:
>> 
>> 1) Dans le blog FDN ci-dessus l'adresse IPv6 affectée au ppp0 n'est pas
>> dans son /48; ce qui voudrait dire qu'il n'y a pas de raison d'affecter
>> une IPv6 du /56 au eth0 des VM tetaneutral.
>> 
>> 2) Pour faire marcher une telle config à FDN, le routeur FDN en amont du
>> modem/routeur de l'abonné devrait avoir une route du type:
>> ip -6 route add range/48 dev ppp-abonné via link-local-ppp-abonné
>> soit chez nous:
>> ip -6 route add range/56 dev eth0-vm via link-local-eth0-vm
>> 
>> > du /56 via une interconnection explicite entre le routeur de
>> > tetaneutral.net et un routeur chez le membre ?
>> 
>> Un lien openvpn?
>
> Bonsoir,
>
> On peut rajouter une regle de routage comme tu le suggere,
> reste a choisir les details pratiques.
>
> Pour la link-local coté routeur on a choisi fe80::31 en statique il
> reste a choisir une regle pour attribuer le link local coté client. 
>
> Une regle automatique basée sur l'IPv4 est en place pour
> l'attribution du subnet IPv6 :
>
> http://wiki.tetaneutral.net/index.php/Architecture

Oui, j'avais lu ça.

> Une regle similaire pour le routage donnerait par exemple fe80::81:XY
> ou XY est le dernier octet de l'IPv4 ecrit en hexadecimal
> pour la link local coté client.
>
> L'avantage d'une regle statique vs le SLAAC c'est que c'est un peu plus
> flexible coté client sur le choix de l'equipement routeur.

Je viens de rajouter ce fe80::81:XY sans problème à ma VM avec SLAAC, ça
à l'air de cohabiter sans problème.

> L'avantage du routé est bien sur la flexibilité et la sécurisation
> potentielle, l'inconvenient est qu'avec nos equipements actuels peu
> puissant on perdra un peu en debit mais ça se corrigera avec
> de nouveaux equipements.

Il est clair que si le but est juste l'hébergement de serveurs, ça n'a
pas d'intérêt, on peut se contenter d'allouer à la VM une /128 (ou
quelques unes, histoire d'éviter les serveurs Web virtuels et héberger 2
DNS sur la même machine, par exemple). Mais si c'est pour donner une
connectivité IPv6 complète at home via un VPN, le routage est la
solution propre.

> Je suis vraiment curieux de savoir comment font les autres hebergeurs
> dans le monde IPv6, ceux auxquels j'ai acces ne proposent pas de
> routage, simplement ce que propose tetaneutral.net actuellement.

Ben FDN a l'air de router...

> Suggestions ?

Poussant mes tests jusqu'au bout, j'avais réussi à avoir un paquet
réponse à mon wget, en forcant l'adresse ipv6 de mon tap maison à celle
de l'eth0 de la VM. Mais voilà, sans NAT en ipv6, pas moyen de forcer le
paquet réponse à continuer vers openvpn... 

Autre solution possible: bridger tout avec l'eth0 de la VM. A la fois le
tap côté VM avec son eth0 et le tap côté LAN avec l'eth0 de ce LAN. 
Ca empêche cependant tout routage ultérieur, donc pas adapté à une
situation genre PME. Et question sécurité, c'est pas terrible.

Cordialement.

-- 

Bernard