(Courriels de diversion: <constituant@caracterisee-embrouillements.com> <compatirais@neurologue-epinglee.com> <faillit@quadrillerai-commentions.com> <carminee@accuser-devaluerais.com> <cambres@edifierons-inexistence.com> <assistais@florins-embourgeoisement.com> <hivernants@ruisseler-diademe.com> <precisaient@superviseur-survoleriez.com> <imaginerons@reempruntais-sacrement.com> <reprogrammation@biaisait-grammaticales.com> )
Bonjour à tous,Ce message fait suite au fil de discussion "IPv6 au CULTe" où j'exposais différentes options pour fournir une connectivité IPv6 globale sur le réseau du CULTe. J'avais fait état du besoin de tester la faisabilité de la solution la plus intéressante techniquement, à savoir faire gérer l'encapsulation IPv6 dans IPv4 dite "6in4" (protocole IP n° 41) du tunnel 6to4rd par un routeur connecté derrière la Freebox et non par la Freebox.
Grâce à l'obligeance du président j'ai pu effectuer des tests montrant que même avec l'option IPv6 désactivée, la Freebox intercepte tout paquet d'encapsulation 6in4 destiné à une adresse IPv6 de la plage 6to4rd allouée aux Freebox, 2a01:e30::/28. Il est donc hélas impossible de gérer l'encapsulation du tunnel 6to4rd sur un routeur connecté derrière la Freebox puisque celui-ci ne verrait jamais arriver le moindre paquet 6in4.
Je me propose aujourd'hui de vous exposer les options restantes : a) pontage de l'IPv6 de la Freebox b) tunnel automatique 6to4 c) tunnel broker d) tunnel point à point avec une machine servant de relais a) Pontage de l'IPv6 de la Freebox ==================================Ce serait dommage de ne pas utiliser l'IPv6 de Free, mais il faut ruser. Le principe est décrit là : <http://ip6.fr/free-broute/>. Le but est d'"apporter" l'IPv6 de la Freebox sur un LAN derrière le mulet, notre routeur, mais comme la Freebox ne permet pas le router, on va le ponter au niveau ethernet grâce à la fonction de pontage de Linux. Donc au niveau de la couche réseau, la Freebox et le LAN restent dans des réseaux IPv4 séparés et routés par le mulet, mais sont dans le même réseau IPv6. La Freebox ne réalise aucun filtrage IPv6 aussi le LAN et ses machines sont totalement exposés, mais pas de panique : au besoin le pontage avec Linux 2.6 autorise de faire du filtrage IPv6 avec ip6tables comme en routage, même si c'est moins "propre".
Le pontage peut être réalisé par le mulet ou bien par une machine séparée connectée en parallèle du mulet entre la Freebox et le LAN. Une machine séparée présente l'avantage d'éviter de devoir modifier la configuration réseau du mulet. En cas de problème, on débranche le pont et tout redevient comme avant.
Une objection a été soulevée : si on active l'option IPv6 de la Freebox, le mulet récupèrera par autoconfiguration une adresse IPv6 globale et une route par défaut, ce qui aura les conséquences suivantes : - les adresses IPv6 retournées par les requêtes DNS faites par les applications compatibles IPv6 tournant sur le mulet seront considérées comme joignables par le noyau et prioritaires sur les adresses IPv4 ; si la connectivité avec ces adresses IPv6 est mauvaise (et de fait, la connectivité IPv6 n'est pas encore aussi bonne qu'en IPv4), ces applications en souffriront ; - les services écoutant en IPv6 sur la machine seront accessibles de partout par son adresse IPv6 globale indépendamment du filtrage IPv4 d'iptables.
A cela on peut répondre qu'il est possible d'empêcher l'autoconfiguration et/ou mettre en place du filtrage IPv6.
L'IPv6 de Free ne permet pas pour le moment d'avoir des reverses DNS, mais ce n'est pas indispensable pour une phase d'essai et de découverte.
Routage sortant : Freebox -tunnel-> relais 6to4rd -IPv6-> destination Routage entrant : source -IPv6-> relais 6to4rd -tunnel-> Freebox Avantages : - bonne latence car le relais 6to4rd est chez Free Inconvénients : - un seul /64 disponible - pontage ethernet nécessaire pour en bénéficier sur un LAN - pas de reverse DNS b) Tunnel automatique 6to4 ==========================Le principe de 6to4 est décrit là : <http://fr.wikipedia.org/wiki/6to4>. Il repose sur le même protocole d'encapsulation 6in4 que le tunnel 6to4rd qui transporte le trafic IPv6 à travers le réseau IPv4 de Free entre les Freebox et le réseau IPv6 de Free. Mais comme il utilise une autre plage d'adresses IPv6, 2002::/16, les paquets entrants ne sont pas interceptés par la Freebox. 6to4 réserve un préfixe IPv6 /48 pour chaque adresse IPv4 publique, il est possible de créer jusqu'à 65536 sous-réseaux /64.
Il est possible de demander une délégation d'autorité pour gérer la zone DNS inverse de son préfixe 6to4 là : <https://6to4.nro.net/>. Cependant ce service est fourni à titre expérimental et peut souffrir de pannes.
Le tunnel 6to4 peut être géré par le mulet servant de routeur IPv6 ; c'est la solution la plus simple et la plus propre puisqu'il est déjà routeur IPv4 et a l'unique adresse IPv4 publique du réseau. Cela permet aussi d'attribuer un préfixe /64 à chaque LAN. Cependant l'objection soulevée au a) s'applique également dans ce cas. Le tunnel peut néanmoins aussi être géré par une autre machine sur un LAN sous réserve de quelques adaptations dans les règles iptables du mulet, et seules les machines connectées à ce LAN pourront en bénéficier.
Routage sortant : CULTe -tunnel-> relais 6to4 local -IPv6-> destination Routage entrant : source -IPv6-> relais 6to4 distant -tunnel-> CULTeLe routage est asymétrique, les paquets émis par chaque source étant routés via le relais 6to4 le plus "proche" (au sens du routage).
Avantages : - il n'y a rien à demander à personne, sauf pour les reverses DNS - bonne connectivité sortante car Free a son propre relais 6to4 - un /48 disponible - reverse DNS possible Inconvénients : - connectivité entrante aléatoire dépendant du relais 6to4 distant c) Tunnel broker ================On désigne par "tunnel broker" un service fournissant une connectivité IPv6 globale à une machine ou un réseau par dessus une connexion IPv4 par le biais d'un tunnel IPv6 dans IPv4, cf. <http://en.wikipedia.org/wiki/Tunnel_broker> (en anglais). A la différence de 6to4, le tunnel est point à point avec un serveur de tunnels au lieu d'être multipoint. D'autres types d'encapsulation que 6in4 peuvent également être utilisés. Les préfixes et adresses IPv6 sont attribués par le tunnel broker qui joue en quelque sorte le rôle de FAI IPv6. Une liste an anglais est disponible là : <http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers>.
Les conditions d'accès et d'utilisation, les protocoles d'encapsulation supportés, la taille des préfixes IPv6 alloués, la possibilité de reverse DNS... dépendent du fournisseur. Ainsi SixXS impose des conditions assez draconiennes pour l'attribution de blocs /64.
Le tunnel IPv6 peut être géré par le mulet servant de routeur IPv6 ou une autre machine comme en 6to4.
Routage sortant : CULTe -tunnel-> relais broker -IPv6-> destination Routage entrant : source -IPv6-> relais broker -tunnel-> CULTe Avantages : - connectivité entrante plus fiable qu'en 6to4 - éventuellement plusieurs /64 dispoibles pour des sous-réseaux - reverse DNS possible chez la plupart des tunnels brokers Inconvénients : - latence dépendant de la proximité du point de présence du tunnel broker - enregistrement nécessaire - conditions d'utilisation pouvant être contraignantes d) Tunnel point à point avec une machine servant de relais ==========================================================Le principe est le même qu'un tunnel broker mais le tunnel est établi avec une machine (de préférence sous GNU/Linux parce que je sais faire) configurée pour servir de relais. Cette machine doit disposer d'une double connectivité IPv4+IPv6 globale, de préférence native et pas par 6to4 ni via un tunnel broker car ça n'aurait guère d'intérêt, et d'un préfixe IPv6 suffisamment grand pour en router une partie vers le tunnel.
Ce serait idéalement un serveur hébergé le plus "proche" possible du réseau de Free/Proxad (au sens du routage IPv4) et disposant d'une bonne bande passante symétrique. Cela ne peut pas être chez Dédibox qui n'offre pas la possibilité d'allouer un préfixe IPv6 à une machine. Qu'en est-il chez OVH, par exemple avec le kimsufi de JDD ?
A défaut cela peut être un bête PC derrière une connexion ADSL, mais la bande passante et la latence seront loin d'être idéales. Avec ma connexion ADSL Nerim Start, je peux allouer autant de /64 que nécessaire dans mon /48. Mais le débit de 256 kbit/s et la latence de 100 ms résultants limiteront fortement les usages possibles. Sans parler de la fiabilité d'un vieux PC de bureau servant de routeur derrière une connexion ADSL. En revanche je peux fournir des reverses DNS.
Routage sortant : CULTe -tunnel-> relais -IPv6-> destination Routage entrant : source -IPv6-> relais -tunnel-> CULTe Avantages : - bonne connectivité IPv4 entre Free et Nerim (peering au FreeIX) - bonne connectivité IPv6 globale de Nerim - suffisamment de préfixes /64 disponibles - reverse DNS possible Inconvénients : - connectivité (forte latence, faible débit) - fiabilité (ADSL, vieux PC) ----------------------------------------------------------------- Les listes de diffusion du CULTe - Pour une informatique libre http://www.CULTe.org/listes/ Pour se desabonner: mailto:linux-31-unsubscribe@CULTe.org?subject=Cliquez_sur_ENVOYER