Resumen

  • RIPE NCC dijo que el 86% de los clientes admitía la red de reunión solo IPv6, con NAT64 para el tráfico IPv4.
  • En la sala principal, el equipo apagó las radios de tres puntos de acceso, activó seis adicionales y aún reportó pequeños problemas.

Tres radios de puntos de acceso se apagaron para mantener la red Wi-Fi de una reunión que probaba IPv6-only. El informe de cierre de RIPE 93 también dejó una cifra llamativa: RIPE NCC dijo que el 86% de los clientes admitía esa configuración. El porcentaje describe capacidad de los dispositivos; el cambio de radios deja constancia del trabajo operativo.

En Sofía, la infraestructura de la reunión cubría cinco pisos. El equipo técnico afirmó que el cableado interno funcionó como debía. Los dispositivos de la red solo IPv6 recibían una dirección IPv6 y recurrían a NAT64 cuando necesitaban tráfico IPv4. La cifra indica que una gran parte de los dispositivos podía usar ese recorrido.

El problema descrito estaba antes del traductor. Algunos puntos de acceso seguían descartando multicast solicited-node, que Neighbor Discovery usa para averiguar la dirección de enlace de un vecino. El RFC 4861 detalla el intercambio: se envía una Neighbor Solicitation a la dirección multicast solicited-node de destino y se espera un anuncio. Cuando el intercambio se completa, el cliente puede enviar tráfico hacia NAT64 para su traducción.

El equipo ya había visto el mismo problema, o uno parecido, en reuniones recientes. El fabricante dijo que lo había corregido, pero RIPE todavía observaba incidencias en Ámsterdam con puntos de acceso de la misma generación. El equipo ejecutó un NDP fixer en el firewall; Menno Schepers dijo que ayudaba con el multicast perdido. En la sala principal apagaron las radios de tres AP y activaron seis AP adicionales. En la sala lateral y el área de café no vieron el mismo patrón. Aun así, el informe dice que quedaron algunos problemas menores.

El relato explica una maniobra técnica; la calidad del servicio requiere otra serie de datos. «El 86% admite esto» describe capacidad. Schepers dijo que el Wi-Fi de la sala principal funcionaba bien «al menos la mayor parte del tiempo». La transcripción no aporta el total de clientes, los resultados por sala ni la serie exportable de NAT64; esos datos permitirían juzgar si la compatibilidad declarada se tradujo en servicio fiable y cómo encajan las dos direcciones.

La gráfica de NAT64 abrió otra pregunta. Durante las preguntas, un participante dijo que dos líneas parecían demasiado simétricas si representaban tráfico de entrada y salida. Schepers respondió que eran ligeramente distintas y que lo revisaría; el moderador dijo que el equipo lo investigaría. La transcripción conserva la pregunta y el compromiso de revisar el gráfico.

El RFC 6146 explica que NAT64 permite a clientes IPv6 llegar a servidores IPv4. Ese trabajo sucede en otro tramo que el multicast de Wi-Fi y Neighbor Discovery. Un gráfico de tráfico traducido puede mostrar actividad en la pasarela y, al mismo tiempo, ocultar si los dispositivos llegaron hasta ella sin fallar. La forma de dos curvas no resuelve esa diferencia.

El equipo movió radios, añadió cobertura, desplegó un desvío y pidió a los asistentes que informaran de los fallos. Es una respuesta operativa concreta. El informe muestra que una cifra de compatibilidad gana valor junto a resultados de campo: la red puede superar la prueba IPv6-only y requerir a la vez que alguien mantenga una sala en línea.

Fuentes primarias: transcripción de la plenaria de cierre de RIPE 93 · sesión del informe técnico RIPE 93 · RFC 4861 · RFC 6146.