Resumen

  • La sección 3.3, añadida en draft-ietf-ippm-stamp-ext-hdr-14, obliga al plano de datos del extremo de salida a proporcionar al reflector las cabeceras IP y de extensión IPv6 recibidas. Si la medición es bidireccional, el extremo de entrada debe proporcionar al emisor las cabeceras de la respuesta.
  • El mecanismo sigue siendo un Internet-Draft. La versión 13 ya contemplaba la selección por longitud y primeros octetos y el indicador C cuando un TLV reconocido no podía utilizarse. La novedad noticiosa es el deber expreso de entrega entre componentes, no un nuevo tipo de error.

Hay una escena fácil de pasar por alto en una prueba activa: la sonda llega al equipo, pero la aplicación que responde no ve todas las cabeceras que examinó el plano de reenvío. Un contador de paquetes recibidos no resuelve esa diferencia. Tampoco lo hace un eco STAMP si el dato original quedó fuera del proceso que debía copiarlo. La revisión del 18 de septiembre toma ese límite de implementación y lo escribe como obligación.

La nueva sección 3.3 exige que el plano de datos del nodo de salida entregue al Session-Reflector las cabeceras IP y de extensión IPv6 del paquete de prueba recibido. En la modalidad de ida y vuelta hay un segundo cruce: el plano de datos del nodo de entrada debe facilitar al Session-Sender las cabeceras recibidas del paquete devuelto. Esta formulación no demuestra fallos en equipos existentes ni acredita que un fabricante haya implementado la propuesta. Identifica la información que debería pasar entre funciones locales para que la reflexión tenga objeto.

El borrador emplea TLV para pedir una cabecera concreta. Cuando el campo solicitado no es cero, la longitud y los primeros ocho octetos de una extensión IPv6 —o los primeros cuatro de una cabecera IP fija— deben coincidir antes de copiarla. Un campo cero apunta a la primera cabecera de longitud adecuada. Si no hay coincidencia, se devuelve el TLV con C=1. Estos detalles aparecen ahora ordenados dentro de los procedimientos; no nacieron todos en la revisión 14. La edición 13 ya incluía la desambiguación, el caso de campo cero y el retorno con C en las definiciones de los campos.

Incluso mencionaba la falta de acceso a las cabeceras desde el plano de datos como posible causa.

La cuestión de gobernanza es qué se considera probado. Un TLV reflejado habla de una cabecera seleccionada entre las que se entregaron al proceso, no de un inventario completo del trayecto ni de la integridad de todos los datos IOAM en cada salto. El indicador C tampoco clasifica por sí solo la causa: selección fallida, cabecera no disponible u otra restricción requieren evidencias locales. Nuestro análisis anterior del mismo indicador trató los límites de MTU, tasa y volumen; aquí el foco está en la nueva exigencia de transmisión de cabeceras hacia los dos extremos de la medición.

La revisión aclara además que el paquete resultante completo, incluidos IP, UDP, STAMP y TLV, debe respetar la MTU del camino. Ya había una salvaguarda de tamaño en el texto anterior. El registro del IETF continúa mostrando una propuesta activa bajo evaluación del director de área y remitida al IESG, no una norma final ni una estadística de despliegue.

Fuentes