GuiGui's Show - LiensUn des adhérents d'ARN (Alsace Réseau Neutre, FAI associatif en Alsace,
http://www.arn-fai.net/) nous indique qu'il n'arrive pas à joindre notre réseau en IPv6 avec sa nouvelle connexion Internet Numéricable. Comme il n'y a pas d'IPv6 chez ce FAI, il utilise Teredo, sorte de 6to4 (une des techniques de transition vers IPv6) qui peut être utilisée dans un contexte NAPT puisque ça repose sur une encapsulation UDP des paquets IPv6 là où 6to4 repose sur une encapsulation IPv4 des paquets IPv6 qui ne permet pas la traversée de NAPT (puisque pas de numéro de port ;) ). Lors d'un « ping6 int.arn-fai.net », il obtient des erreurs « Destination unreachable: Address unreachable ». Chose curieuse : le « From: » est l'IPv6 du client lui-même !
Évidemment, les autres réseaux (ipv6.google.com, wikipedia,...) sont accessibles en IPv6. Aucun problème pour joindre notre réseau en IPv4 depuis cette connexion Numéricable.
Pour pouvoir reproduire ce problème sur une ligne Numéricable, j'ai utilisé le logiciel Miredo (
http://www.remlab.net/miredo/) qui peut agir comme client/serveur/relai Teredo. C'est dispo dans les dépôts Debian et ça juste fonctionne sans prise de tête. Il est livré avec une configuration client donc il suffit de « service miredo start » pour le lancer. Un « tail -f /var/log/syslog » vous confirmera si le tunnel est OK.
Je vous passe les heures à essayer de comprendre l'origine du problème... Problème de routage ? Préfixe v6 d'ARN trop spécifique donc ignoré du relai teredo ? Upstreams d'ARN qui failent ou gue-guerre commerciale ?
Pour comprendre le problème, il faut lire la doc. On va commencer par les définitions générales. Voir :
https://fr.wikipedia.org/wiki/Teredo_%28protocole%29
« Teredo définit plusieurs types de nœud :
* Un client Teredo est un hôte qui dispose d'une connectivité IPv4 à l'Internet derrière un NAT et utilise le protocole de tunneling Teredo pour accéder à l'Internet IPv6. Les clients Teredo reçoivent une adresse IPv6 qui commence par le préfixe Teredo 2001:0000::/32
* Un serveur Teredo est un hôte connu qui est utilisé pour la configuration initiale d'un tunnel Teredo. Un serveur Teredo ne transmet jamais tout le trafic pour le client (en dehors des pings IPv6), et a donc de très modestes besoins en bande passante (quelques centaines de bits par seconde et par client au maximum), ce qui permet à un serveur unique de subvenir à un grand nombre de clients. En outre, un serveur Teredo peut être mis en œuvre de manière totalement sans état, utilisant ainsi la même quantité de mémoire indépendamment du nombre de clients qu'elle soutient.
* Un relais Teredo est un hôte connecté à la fois en IPv4 et en IPv6, et par lequel passe tout le trafic destiné à l'Internet v6, il a donc de gros besoins en bande passante. »
Pour comprendre la suite, il faut lire un bout du RFC 4380 (
https://tools.ietf.org/html/rfc4380#section-3.4) :
« Teredo clients have to discover the relay that is closest to each
native IPv6 or 6to4 peer. They have to perform this discovery for
each native IPv6 or 6to4 peer with which they communicate. In order
to prevent spoofing, the Teredo clients perform a relay discovery
procedure by sending an ICMP echo request to the native host. This
message is a regularly formatted IPv6 ICMP packet, which is
encapsulated in UDP and sent by the client to its Teredo server; the
server decapsulates the IPv6 message and forwards it to the intended
IPv6 destination. The payload of the echo request contains a large
random number. The echo reply is sent by the peer to the IPv6
address of the client, and is forwarded through standard IPv6 routing
mechanisms. It will naturally reach the Teredo relay closest to the
native or 6to4 peer, and will be forwarded by this relay using the
Teredo mechanisms. The Teredo client will discover the IPv4 address
and UDP port used by the relay to send the echo reply, and will send
further IPv6 packets to the peer by encapsulating them in UDP packets
sent to this IPv4 address and port. In order to prevent spoofing,
the Teredo client verifies that the payload of the echo reply
contains the proper random number. »
Donc le client Teredo fait un test de connectivité (un echo request icmpv6) en émettant un paquet avec comme IPv6 source l'IP qu'il a synthétisé dans 2001::/32 et en passant par son serveur Teredo qui le transmet à la destination.
La destination doit donc répondre directement au client... et doit donc avoir une route vers 2001::/32. Ce préfixe peut-être annoncé par tout opérateur réseau qui veut monter des relais Teredo. C'est, avec la racine DNS et le 6to4, un des exemples d'utilisation de l'anycast. Actuellement, Hurricane Electric semble être un des gros fournisseurs de relais Teredo/6to4 (il faut dire qu'avec les tunnels 6in4 c'est leur business :D ). La réponse de la destination sera donc prise en charge par le relai Teredo le plus proche et retranmise au client Teredo en IPv4.
Attention : en anycast, « le plus proche » n'a aucune signification géographique ! Cette notion s'apprécie en nombre de réseaux traversés et en fonction des politiques de routage propre à chaque opérateur ! Exemple, chez ARN, nous voyons deux routes pour joindre un relai Teredo (
http://lg.arn-fai.net/prefix_detail/hwhost-1/ipv6?q=2001%3A%3A/32) : une directement connectée (Hurricane Electric), l'autre en 3 sauts. Pourtant, c'est le chemin le plus long qui l'emporte car on a diminué la local-pref sur HE afin de forcer le trafic à sortir par Cogent car notre lien avec HE est un tunnel 6in4 à cause d'une gu-guerre commerciale entre Cogent et HE qui empêche de joindre l'un quand on est client de l'autre sauf à monter ce genre de tunnels crades (cf
http://shaarli.guiguishow.info/?X_2rrQ).
Si le client reçoit une réponse de la destination, il reçoit également, dans les headers, l'adresse IPv4 du relai Teredo à utiliser pour établir la communication. S'il ne reçoit pas la réponse, un message « Destination unreachable: Address unreachable » est émis pour informer la couche applicative...
Voici ce que l'on voit côté destination (j'ai remplacé l'IPv6 source par une factice ;) ) :
IP6 2001:0::1 > int.arn-fai.net: ICMP6, echo request, seq 46782, length 26
IP6 int.arn-fai.net > 2001:0::1: ICMP6, echo reply, seq 46782, length 26
IP6 2001:0::1 > int.arn-fai.net: ICMP6, echo request, seq 1, length 64
IP6 int.arn-fai.net > 2001:0::1: ICMP6, echo reply, seq 1, length 64
IP6 2001:0::1 > int.arn-fai.net: ICMP6, echo request, seq 2, length 64
IP6 int.arn-fai.net > 2001:0::1: ICMP6, echo reply, seq 2, length 64
Pourquoi la réponse des machines du réseau ARN ne revenait pas au demandeur ? Parce que nous appliquons des filtres sur les annonces BGP que nous recevons pour ne pas prendre en compte les martians (les plages d'adresses IP qui n'ont rien à faire sur Internet : documentation, RFC1918, benchmark, link-local,...) comme il est recommandé de le faire. Sauf que ce filtre était trop restrictif et il amenait à ignorer 2001::/32. Impossible donc pour les machines de notre réseau de répondre puisqu'aucune route... Notons que le message d'erreur n'est pas clair... Pour moi, « Destination unreachable: Address unreachable » s'etend d'un point de vu du serveur Teredo. Je pensais donc que c'était ce dernier qui n'avait pas de routes pour joindre le réseau d'ARN. :-
Pour les admins réseaux : 6to4 et Teredo ne sont pas dépréciés à l'IETF ! Seul l'usage de l'anycast pour joindre, en IPv4, le relai 6to4 le plus proche est déprécié par le RFC 7526, il faut contacter le relai 6to4 en unicast ou le relai Teredo selon le mécanisme décrit ci-dessus. Donc 192.88.99.0/24 pourra bientôt être ajouté à la liste des martians à filtrer mais 2001::/32 (Teredo) et 2002::/16 (6to4) restent utilisables et ne doivent donc pas être filtrés !
(
Permalink)