Resumen

  • RFC 3489 combinaba tres pruebas Binding para nombrar seis situaciones, aunque cada respuesta pertenecía a un socket, servidor, destino, reino de direcciones y momento concretos.
  • RFC 5389 mantuvo STUN como observador de una dirección mapeada, pero dejó de tratar el tipo como prueba de travesía. Hacía falta comprobar la ruta con el par real y disponer de relevo.

En 2003, RFC 3489 ofrecía un árbol de decisión elegante. La prueba I pedía una respuesta normal y comparaba el socket local con MAPPED-ADDRESS. La II solicitaba respuesta desde otra IP y otro puerto. La III cambiaba solo el puerto. Una segunda prueba I hacia CHANGED-ADDRESS comparaba el mapeo. El árbol distinguía Internet abierto, cortafuegos UDP simétrico y cuatro clases de NAT.

El problema no era que las respuestas fueran inventadas. Era su alcance. La experiencia usaba un socket local, un servidor y su dirección alternativa, una dirección de paso a través de uno o varios traductores, un reino y un instante. El propio RFC exigía cambiar de dirección o puerto local al repetirla, porque el estado anterior podía invalidar el resultado nuevo. La medición alteraba la superficie observada.

La etiqueta también borraba el destino. Un mapeo podía mantenerse frente al servidor STUN y cambiar frente al par deseado. El filtro podía admitir una fuente y rechazar otra. Una cadena de NAT aparecía como el comportamiento del elemento más restrictivo sin revelar qué caja, regla o temporizador había tomado la decisión. “Tipo de NAT” convertía una relación en una supuesta propiedad permanente.

El reino de direcciones imponía otro límite. Un servidor situado fuera del ancestro común podía devolver una dirección inútil para el otro participante. Dos pares detrás del mismo NAT podían fracasar al usar sus direcciones externas. MAPPED-ADDRESS significaba que aquel servidor había observado aquel origen; no significaba que cualquier tercero pudiera alcanzarlo.

La vida de la asociación era una inferencia adicional. El cliente conservaba una asociación y dejaba envejecer otra para estimar el vencimiento. Pero la sobrecarga podía cambiar los tiempos, distintas asociaciones podían recibir plazos distintos y un reinicio podía falsear el cálculo. El valor aprendido no era un arrendamiento prometido por el NAT.

La seguridad no ampliaba el alcance de la prueba. Un secreto compartido y la integridad del mensaje podían autenticar ciertos intercambios, sin demostrar que la dirección funcionaría para otro destino. RFC 5389 documentó después un problema de dirección mapeada incorrecta que, en ciertas topologías, no se resolvía solo con criptografía. Testimonio auténtico y conclusión válida eran recibos separados.

RFC 5389 describió con franqueza la experiencia acumulada: STUN clásico no bastaba como solución desplegable. Una dirección servía a veces y otras no; el protocolo no podía saberlo ni remediarlo. Muchos NAT no cabían en las categorías. La revisión retiró de la base los atributos antiguos de cambio de respuesta y redefinió STUN como utilidad dentro de una solución más completa.

RFC 5780 separó después conducta de mapeo y conducta de filtrado. ICE, en RFC 8445, reunió candidatos, creó pares y realizó controles entre los participantes reales antes de nominar una ruta. TURN, hoy en RFC 8656, añadió relevo cuando la ruta directa no existía. La pregunta pasó de “¿qué NAT es?” a “¿qué par funciona ahora y cuál es el respaldo?”

La lente de Heng Lu hace visible el cambio. Una especificación inicial mínima conserva la herramienta común y deja que cada uso decida servidores, autenticación, tiempo y repliegue. Separar capas de realidad evita llamar éxito a una cadena incompleta: socket, respuesta STUN, tuple observado, control del par, nominación, tráfico y resultado de aplicación.

Clasificar sigue siendo útil para resumir evidencia. Lo incorrecto es borrar las condiciones que la produjeron. RFC 3489 nombraba el dispositivo; RFC 5389 devolvió la autoridad a la ruta comprobada.

Fuentes