Resumen

  • RFC 3316 propuso reutilizar un acuse TCP nuevo, un informe de recepción RTCP o una respuesta SIP como evidencia positiva de que tráfico saliente reciente había cruzado el router de primer salto.
  • La inferencia tenía un alcance limitado: podía refrescar el estado del vecino y evitar una sonda NUD, pero no demostraba que la aplicación hubiera terminado, que la conectividad fuese duradera ni que cualquier paquete entrante validara el camino de salida.

En una sesión IPv6 celular de principios de siglo, el paquete costoso no siempre llevaba datos del usuario. A veces servía para formular una pregunta de control que el host ya podía responder con evidencia obtenida en otra capa.

Neighbor Unreachability Detection, NUD, mantiene una valoración reciente de si el siguiente salto sigue siendo alcanzable. Cuando esa confianza caduca mientras continúa el tráfico, el host puede enviar una Neighbor Solicitation unicast y esperar una Neighbor Advertisement solicitada. En Ethernet, el intercambio encaja junto a la resolución de direcciones. Los enlaces GPRS y UMTS descritos por RFC 3316 se parecían, en cambio, a una conexión punto a punto: el host celular tenía un único vecino, el router por defecto ya descubierto, y no había direcciones de capa de enlace que resolver.

Desaparecía la resolución, no la necesidad de detectar un primer salto averiado.

El perfil planteó entonces una pregunta distinta: ¿había demostrado ya otro protocolo que un paquete reciente avanzó en la dirección de salida?

La regla general de Neighbor Discovery ofrecía la lógica. Recibir un nuevo acuse TCP permite saber que datos enviados antes llegaron al par remoto. Si el destino está fuera del enlace, esos datos no pudieron alcanzarlo sin atravesar primero el router del emisor. La confirmación de extremo a extremo contiene así un hecho local: el siguiente salto era alcanzable cuando pasó ese paquete. El host puede usar ese hecho para actualizar su Neighbor Cache en vez de gastar otro intercambio solo para sondear el router.

RFC 3316 aplicó el mismo razonamiento a las aplicaciones celulares basadas en UDP. UDP no confirma entrega por sí solo, de modo que la aplicación debía exponer una señal con la relación causal correcta. Para RTP, un bloque de recepción RTCP que indicase que algunos paquetes habían llegado al par podía servir. Para SIP, una respuesta a una petición mostraba que la petición salió y llegó. Si el host celular actuaba como servidor SIP, enviar una respuesta no aportaba por lo general esa certeza; recibir después el ACK sí podía demostrar que la respuesta al INVITE alcanzó el otro extremo.

No eran luces verdes intercambiables. Cada señal debía implicar la entrega de tráfico saliente reciente. Un datagrama entrante sin relación no bastaba. Tampoco un Router Advertisement no solicitado: ese mensaje demostraba el trayecto desde el router hacia el host, mientras NUD necesitaba confianza en la dirección del host hacia su siguiente salto. Observar movimiento no equivale a probar el camino que está bajo examen.

El estado resultante era temporal. La confirmación de una capa superior podía colocar la entrada del Neighbor Cache en REACHABLE durante un intervalo limitado. Sin nuevas pruebas, la entrada envejecía a STALE; al enviar de nuevo podía pasar por DELAY y luego PROBE, cuando reaparecían las Neighbor Solicitation dedicadas. RFC 3316 no eliminó NUD. Evitó repetir la pregunta mientras el tráfico activo ya ofrecía una respuesta válida.

La razón práctica era la radio. El documento trataba el ancho de banda celular como un recurso limitado y señalaba que el usuario podía pagar por volumen. Eliminar mensajes innecesarios podía proteger capacidad y coste. Sin embargo, el RFC no midió ahorro de paquetes, batería o factura. Describió una política de implementación derivada de la topología y de la evidencia que ya producían los flujos.

El mecanismo siguió presente. RFC 7066 sustituyó a RFC 3316 en 2013, amplió el modelo a EPS, conservó TCP, RTCP y SIP y añadió la respuesta DNS como posible confirmación. Esa continuidad indica que la inferencia conservó valor en el perfil, no qué dispositivos la implementaron ni cuántas sondas evitó.

La enseñanza histórica no es que la aplicación deba gobernar el encaminamiento. Es que una máquina de estados puede reutilizar evidencia de otra capa cuando la implicación está escrita con precisión. El informe remoto habla del primer salto porque el paquete saliente tuvo que cruzarlo. La conclusión termina ahí: un informe RTCP no prueba buena calidad de medios; una respuesta SIP no prueba una llamada completada; un router alcanzable no prueba un servicio disponible; y la evidencia de un paquete no certifica el siguiente.

Fuentes: RFC 3316, RFC 2461, RFC 4861, RFC 7066, RFC 7849, RFC 8504, RFC 3550 y RFC 3261.