Resumen

  • La revisión 05 del borrador PROBE incorpora experiencia de despliegue y dice que compararlo con ping parece haber inducido una suposición errónea sobre el paquete y una salida con apariencia de éxito.
  • El texto mejora la explicación, pero la operación necesita además un comprobante que una el código de respuesta, los bits originales, la etiqueta visible y la prueba que valida esa transformación.

La línea parece tranquilizadora antes de leerla completa:

64 bytes from 192.0.2.2: icmp_seq=1 ttl=63 active=1 ipv4=0 ipv6=0

Hay una dirección que responde, una secuencia y un TTL. La forma recuerda al ping que muchos operadores usan durante una avería. El ojo reconoce éxito y puede pasar por alto los dos ceros del final, aunque estos indiquen que el estado de protocolo buscado no está presente.

Ese es el problema que documenta la revisión 05 de PROBE. El nuevo apéndice explica que las personas reconocen patrones y pueden interpretar la salida como positiva. La observación abre un límite de gobernanza: la respuesta de red y la decisión del operador no son el mismo objeto. Una presentación familiar puede otorgarse autoridad sobre ambos sin que nadie la haya autorizado expresamente.

PROBE formula otra pregunta

Ping comprueba conectividad bidireccional entre quien sondea y el destino. PROBE envía una solicitud ICMP Extended Echo a una interfaz proxy para consultar una interfaz distinta. La interfaz examinada puede estar en el mismo equipo o en un vecino directamente conectado. La comunicación bidireccional exigida es entre el origen y el proxy, no necesariamente entre el origen y la interfaz examinada.

Por eso la respuesta no cabe en un simple “llegó”. Para una interfaz local, el bit A indica actividad; otros dos bits indican por separado IPv4 e IPv6. La tabla del borrador incluye 1/0/0: interfaz activa sin IPv4 ni IPv6 activos. Otros códigos distinguen una consulta mal formada, una interfaz inexistente, ninguna entrada en la tabla correspondiente o varias interfaces que coinciden.

Que el proxy conteste demuestra que procesó la solicitud. No demuestra que exista el estado deseado. Si la aplicación convierte éxito del transporte en éxito operativo, borra precisamente la diferencia que debía medir.

La metáfora llegó al formato

El apéndice registra una consecuencia anterior. El RFC 8335, de 2018, describió PROBE como parecido a ping. La revisión 05 sostiene que esa frase parece haber llevado a implementadores a pensar que también se parecía el formato del paquete. Según el texto, las implementaciones iniciales terminaron infringiendo la disposición normal de extensiones del RFC 4884.

El borrador bis mantiene compatibilidad con ese comportamiento: la estructura de extensión contiene exactamente un objeto de identificación de interfaz y los datos opcionales quedan fuera. Advierte que otros usos de extensiones ICMP no deben imitarlo. También afirma que todas las implementaciones conocidas del RFC 8335 son compatibles y que las aclaraciones no alteran el comportamiento en el cable ni exigen migración.

No es una acusación contra todo el software ni una prueba de causalidad total. Es algo más preciso: el propio borrador deja constancia de que una comparación conocida alentó un atajo y que el coste de compatibilidad de aquel atajo todavía condiciona el texto sucesor.

Experiencia no equivale a cobertura

El historial del Datatracker fecha la carga el 6 de septiembre de 2026 UTC, aunque el encabezado del documento dice 7 de septiembre. El subestado cambia de Revised I-D Needed a AD Followup. Sigue siendo un Internet-Draft destinado a Proposed Standard, no un RFC aprobado.

La diferencia oficial respecto de la revisión 04 muestra la incorporación del apéndice. En mayo, el Area Director responsable había pedido experiencia de despliegue, incluido el paso por Internet público y por dispositivos intermedios. La respuesta dice que Extended Echo está apagado por defecto, debe controlarse estrechamente y se usará sobre todo dentro de un dominio donde una organización controla los equipos del trayecto. Hubo experimentos individuales a través de partes de Internet, pero no resultados amplios.

El límite evita transformar casos en censo. La revisión también restringe las direcciones a unicast, precisa que AFI 1 consulta ARP, AFI 2 la caché de vecinos IPv6 y otros valores producen No Such Table Entry, y deja el Flow Label sin especificar. Son precisiones del modelo, no una certificación general.

El permiso de consulta no corrige la pantalla

El documento contiene salvaguardas razonables. Extended Echo se desactiva por defecto. Los operadores deberían habilitarlo sólo donde haga falta, limitar los prefijos de origen a redes de gestión autorizadas y controlar la frecuencia. Tampoco debe filtrar información entre instancias de red.

Esas reglas gobiernan quién pregunta, cuánto pregunta y qué frontera no puede cruzar la información. No prueban que el cliente muestre la respuesta sin distorsión. Una consulta autorizada puede seguir produciendo una interpretación equivocada.

El apéndice A.1 ya recomienda texto completo para los códigos de error y ofrece frases claras para las combinaciones A/IPv4/IPv6. Una aceptación operativa debería ir un paso más allá y conservar: el identificador consultado; si la interfaz era local o adyacente; el código y los bits brutos; la etiqueta y severidad visibles; las versiones de cliente y servidor; un vector de prueba para cada estado negativo, ambiguo o múltiple; y quién aprobó la representación.

Ese comprobante entre resultado y pantalla es análisis de Daniel Kade, no una obligación del IETF. Sirve para probar que un intercambio exitoso no se convirtió en una afirmación falsa sobre el servicio.

Las analogías no tienen que desaparecer. Deben terminar justo donde diverge el modelo de estado. Si la especificación dice “como ping”, las pruebas han de enumerar dónde deja de serlo. Si el cliente toma su forma visual, la ausencia debe dominar la línea en vez de esconderse al final.

Fuentes

  1. Borradores recientes del IETF
  2. Ficha de PROBE en Datatracker
  3. Historial de revisiones
  4. Revisión 05
  5. Revisión 04
  6. Comparación oficial 04–05
  7. RFC 8335
  8. RFC 4884
  9. RFC 5706
  10. RFC 2151
  11. RFC 8343
  12. Repositorio de PROBE
  13. Revisión del Area Director sobre la versión 04
  14. Lu Heng — Minimum Initial Specification, Localized Future Decision
  15. Lu Heng — Running Code Primary