Résumé

  • RIPE NCC indique que 86 % des clients prennent en charge le réseau de réunion IPv6 seul, avec NAT64 pour le trafic IPv4.
  • Dans la salle principale, l’équipe a coupé les radios de trois points d’accès et en a activé six autres; de petits problèmes subsistaient.

Trois radios de points d’accès ont été coupées pour stabiliser le Wi-Fi d’une réunion qui testait justement un réseau IPv6 seul. Dans son bilan de clôture de RIPE 93, RIPE NCC donne aussi un chiffre rassurant: 86 % des clients prenaient en charge cette configuration. Le pourcentage décrit la capacité des appareils; le changement radio décrit le travail du réseau.

Le réseau couvrait cinq étages à Sofia. L’équipe technique dit que le câblage interne a fonctionné comme prévu. Les appareils du groupe IPv6 seul recevaient une adresse IPv6; NAT64 assurait la traduction nécessaire pour joindre des services IPv4. Le chiffre de 86 % indique qu’une large part des appareils pouvait suivre ce parcours.

Le défaut rapporté se trouvait plus près des appareils que du traducteur. Certains points d’accès continuaient à perdre le multicast solicited-node utilisé par Neighbor Discovery pour trouver l’adresse de liaison d’un voisin. La section 7.2 du RFC 4861 décrit cette étape: l’émetteur envoie une Neighbor Solicitation vers l’adresse multicast solicited-node de la cible, puis attend la réponse. Quand cet échange aboutit, le trafic peut continuer vers NAT64 pour la traduction.

L’équipe avait déjà rencontré un problème identique ou similaire lors de réunions précédentes. Le fournisseur avait annoncé un correctif; RIPE continuait pourtant à voir des symptômes au bureau d’Amsterdam avec des points d’accès de la même génération. L’équipe a lancé un NDP fixer sur le pare-feu; Menno Schepers dit que cela a aidé. Dans la salle principale, elle a ensuite éteint les radios de trois bornes et en a activé six supplémentaires. La salle secondaire et l’espace café n’ont pas montré le même problème. Le rapport indique que de petits soucis subsistaient malgré le changement.

Ce compte rendu décrit une intervention; la qualité de service exige d’autres chiffres. « 86 % prennent en charge cette configuration » décrit la capacité des appareils. Schepers dit que le Wi-Fi fonctionnait correctement « au moins la plupart du temps » dans la salle principale. La transcription ne donne ni le nombre d’appareils, ni les résultats par salle, ni l’export du graphique NAT64; ces données montreraient si la capacité annoncée est devenue un service fiable et si les directions tracées se réconcilient.

Le graphique NAT64 a suscité une autre question. Un participant a trouvé les deux lignes trop symétriques pour représenter le trafic entrant et sortant. Schepers a répondu qu’elles étaient légèrement différentes et qu’il allait vérifier; le président a dit que l’équipe allait s’en occuper. La transcription conserve la question et l’engagement de vérifier le graphique.

RFC 6146 décrit NAT64 comme un mécanisme permettant à des clients IPv6 d’atteindre des serveurs IPv4. Cela se passe à un autre endroit du parcours que le multicast Wi-Fi et Neighbor Discovery. Un graphique à la passerelle peut montrer le trafic traduit sans révéler si les appareils ont atteint cette passerelle sans difficulté. La forme de deux courbes ne répond pas, à elle seule, à cette question.

L’équipe a déplacé des radios, activé d’autres bornes, ajouté un contournement et demandé aux participants de signaler les problèmes. C’est du travail d’exploitation. Le bilan montre qu’un pourcentage de compatibilité gagne à être accompagné des résultats de terrain: le réseau peut réussir l’essai IPv6 seul et demander encore l’intervention d’un technicien dans une salle.

Sources primaires: transcription de la plénière de clôture de RIPE 93 · session du rapport technique RIPE 93 · RFC 4861 · RFC 6146.