Resumen

  • El RFC 4957 sitúa las notificaciones de capa de enlace como entradas para detectar el apego a la red, no como un resultado IP terminado.
  • Un cambio de punto de acceso puede mantener la misma subred, y una modificación de configuración puede ocurrir sin un evento de enlace nuevo.

«Link up» parece una conclusión: la asociación de radio terminó, la estación Wi-Fi se unió al punto de acceso o Ethernet ya puede enviar tramas. En la telemetría de incidencias, el paso siguiente suele ser llamarlo «servicio recuperado». El RFC 4957 obliga a separar ambas afirmaciones.

El documento informativo, editado entre otros por Suresh Krishnan, reúne los datos que distintas tecnologías de acceso pueden entregar a IP al cambiar un equipo de punto de apego. Esos datos aceleran la búsqueda de una configuración correcta. No certifican que haya una dirección útil, una puerta de enlace funcional ni una aplicación disponible.

Una nueva conexión de capa de enlace puede hacer que el host busque indicios adicionales, como una solicitud de router. El RFC afirma que la notificación por sí sola no reúne toda la información que necesita el proceso de detección de apego. Siguen contando los prefijos anunciados, la alcanzabilidad de la puerta de enlace y otras pruebas IP. Es un disparador de la máquina de estados, no su estado final.

El roaming Wi-Fi ilustra la diferencia. Un dispositivo puede salir de un punto de acceso y entrar en otro sin abandonar la misma subred IP. Interpretar cada asociación como una reconfiguración produce acciones y métricas erróneas. También existe el caso inverso: una renumeración IPv6 puede exigir un cambio IP sin que aparezca un nuevo aviso de enlace activo.

El RFC admite además un enlace activo no determinista cuando la interfaz está preparada pero la red todavía podría bloquear la transmisión. Incluso una indicación posterior determinista describe una condición de enlace definida por la implementación. No demuestra que terminó SLAAC o DHCP, que la política permite el tráfico, que DNS funciona, que un servicio remoto respondió ni que el cliente vio un resultado.

Para un operador, el problema es de diseño de evidencia. link_up puede ser una observación local muy útil: interfaz, punto de apego, instante y contexto tecnológico. No debe rebautizarse como online, contarse como recuperación de aplicación ni cerrar por sí solo un ticket. Cada nombre posterior afirma algo que el evento no vio.

Conviene usar una escalera: evento de enlace, estado de dirección y prefijo, prueba de puerta de enlace, resultado del resolutor, respuesta autenticada del servicio y confirmación visible para el cliente. Cada nivel tiene un observador, un dominio de fallo y una responsabilidad distintos. Ninguna parte debe declarar el resultado de otra sin su evidencia.

La lección de RFC 4957 es limitada y útil: un evento de enlace prueba un evento de enlace. Su valor es iniciar la siguiente prueba. Se vuelve engañoso cuando se vende como recibo de una ruta, un servicio o una experiencia que nunca observó.

Fuentes