NAT Meter: un poco de historia
06/07/2021
Por Alejandro Acosta, Coordinador de I+D en LACNIC y Agustín Formoso, Colaborador
Desde hace algunos años que desde LACNIC Labs corremos un experimento para estimar la adopción de NAT en la región LAC. En el último año el mecanismo por el cual medíamos NAT ha quedado sin soporte por las diferentes plataformas, y amenaza la viabilidad de la medición. En este artículo les mostramos qué hemos podido medir hasta ahora y algunos posibles siguientes pasos.
¿Qué es NAT, y por qué medirlo?
El término NAT proviene de la sigla del inglés Network Address Translation – sería traducido al español a algo como traducción de dirección de red. Es un mecanismo que permite, entre dos redes, traducir direcciones IP entre una y otra. La tecnología de NAT se puede implementar en diferentes formas, no es el objetivo de este artículo explorarlas, pero sí es importante saber que la implementación de NAT 4-4 es un factor importante a la hora de evaluar los factores detrás de la adopción de IPv6.
A grandes razgos, el uso de NAT 4-4 nos permite reciclar un mismo bloque de direcciones IPv4 entre un grupo cada vez más grande de dispositivos. Si bien a primera vista podría parecer que el uso de NAT 4-4 es conveniente desde un punto de vista estratégico, termina siendo una mala opción si se lo compara con una estrategia a largo plazo como lo es implementar IPv6 en la red (y por ende contar con un espacio de numeración más que suficiente).
¿Cómo medirlo?
El mecanismo que usamos en LACNIC Labs es relativamente simple, consiste en disparar solicitudes WebRTC desde un script en JavaScript hacia determinados endpoints que tienen algunas propiedades específicas. Estos endpoints son tres, de los cuales el primero es el propio cliente (localhost), y los otros dos son servidores STUN operados por LACNIC (uno IPv4-only y uno IPv6-only). Lo importante de las consultas WebRTC es que brindan información de red acerca del cliente, en particular las direcciones IP que tiene. En el mundo de las aplicaciones web esta información es necesaria para que las aplicaciones basadas en WebRTC puedan establecer una sesión entre peers; nuestro script simplemente usa esta funcionalidad para descubrir esas direcciones. Una nota importante es que estas consultas WebRTC son diferentes de un servicio típico de descubrimiento de direcciones (como what-is-my-ip), el mecanismo a través de WebRTC nos brinda la información de las direcciones que están siendo utilizadas detrás de “cajas intermedias” (como NATs), situación en la cual los servicios típicos fallan.
El diagrama a continuación explica el mecanismo detrás del experimento, de principio a fin. Los endpoint mencionados anteriormente son consultados en el paso 2. Analicemos un poco más qué sucede dentro de ese paso:
2.a – Se establece una sesión WebRTC RTCPeerConnection entre el navegador y él mismo. Se obtiene información acerca de las direcciones IP utilizadas por el navegador.
2.b – Se hace lo mismo entre el navegador y los servidores STUN operados por LACNIC.
2.c – Si hay alguna diferencia entre lo que perciben los servidores remotos (2.b) y lo que percibe el navegador acerca de él mismo (2.a), entonces se marca el resultado con un flag. Este flag es nuestra “señal” indicando si el cliente se encuentra o no detrás de NAT.
Resultados
Mirando en retrospectiva, los resultados se encuentran alineados con nuestras expectativas: hay un alto uso de NAT ne la región. Esto no debería ser una sorpresa para nadie.
A continuación se muestra una línea del tiempo con el porcentaje de mediciones que tuvieron flag de NAT, agrupados por día (burbujas celestes) y en una ventana móvil de los últimos 30 días (linea azul):1 dia30 díasSeptember2018November2018January 2019March 2019May 2019July 2019September2019November2019January 2020050100
(Acceso libre, no requiere suscripción)
Para ese período de tiempo la media es de 86%, donde hay intervalos mayores a 95% para la ventana de 30 días.
Medir NAT desde un navegador se hace difícil
Pero como dice el dicho, “there ain’t no such thing as a free lunch”, que en castellano se traduciría a “no hay tal cosa como un almuerzo gratis”, o también “nada es gratis”. La conveniencia de correr experimentos desde un navegador trae por contrapartida depender del navegador donde uno corre el experimento. Y los navegadores son plataformas vivas, que sufren cambios cada mes, muchas veces sin consentimiento de usuarios, desarrolladores, u operadores de los diferentes servicios de infraestructura: la industria acompaña los cambios impuestos por la plataforma, o cambia de plataforma. Un ejemplo es el tráfico que se generó hacia los root servers a partir de un feature dentro de Chromium (proyecto base de varios navegadores populares), pueden leer más en este post en el blog de APNIC (en inglés).
El market share que percibimos de Google Chrome es alto: más de un 70% de los experimentos que corremos se estan ejecutando dentro de Chrome. Un cambio dentro de las políticas de Chrome puede tener un gran impacto en el experimento. Y de hecho ese cambio de políticas llegó en Chrome versión 78. En el gráfico siguiente comparamos el release de sucesivas versiones de Chrome con los resultados exitosos del experimento. Nótese que el market share, o adopción de una versión de Chrome comienza a bajar al mismo tiempo que la sigueinte versión comienza a subir, naturalmente ya que un navegador se actualiza y comienza a reportarse con su nueva versión. Al momento del release de Chrome v78 la cantidad de experimentos exitosos baja a la mitad, y al momento del release de v80 pasa a practicamente 0.Experimentos exitososv76v77v78v79v80v81November2019December2019January 2020February 2020March 2020April 2020May 20207141816161825050100
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.