Resumen

  • El RFC 10030, publicado en agosto de 2026, encapsula mensajes NTP de cliente-servidor y modo simétrico en eventos PTP unicast para aprovechar sellos de tiempo de NIC y correcciones de relojes transparentes compatibles.
  • La corrección PTP no se puede autenticar, los valores corregidos negativos se descartan y el root delay no cambia; la elección de fuente y la evaluación del error permanecen en NTP.

El límite físico detrás del nuevo transporte

Muchas tarjetas de red solo pueden marcar una fracción del tráfico recibido. Para no agotar esa capacidad, sus filtros identifican PTP por transporte, tipo de mensaje o puerto. El NTP convencional que llega por UDP 123 puede quedar fuera, aunque el mismo hardware sea capaz de marcar un evento PTP cerca del cable.

El RFC 10030 aprovecha esa realidad sin convertir PTP en sustituto de NTP. Define un TLV de organización que contiene el mensaje NTP y lo coloca dentro de un evento PTP unicast. Admite los modos cliente, servidor y simétrico; no define el modo broadcast. El subtipo 0x1, bajo el OUI 00-00-5E de IANA, queda registrado como Network Time Protocol Message.

La respuesta debe volver por el mismo transporte. No puede ser más larga que la solicitud, para impedir amplificación. Si se espera una respuesta mayor, el solicitante puede rellenar el evento. Cuando la respuesta sirve para sincronizar, conviene igualar longitudes para no crear una diferencia de retardo en trayectos que no soportan PTP de extremo a extremo.

El RFC Editor anunció el documento el 14 de agosto de 2026. Miroslav Lichvar figura como autor y draft-ietf-ntp-over-ptp-08 como borrador final del trabajo del grupo Network Time Protocols.

El puerto que abre el filtro

Sobre UDP, el documento recomienda el puerto de eventos PTP 319 como origen y destino. El filtro de la NIC puede así producir el sello de recepción. La contrapartida es explícita: si el cliente usa la aleatorización de puerto de origen del RFC 9109, el filtro limitado a 319 puede dejar de marcar sus paquetes.

Network Time Security sigue funcionando dentro del mensaje NTP. Pero su autenticación no cubre por arte de magia los campos PTP exteriores. El operador recibe una ventaja de medición y una exposición de puerto distinta; debe evaluar ambas, no resumirlas como una mejora universal de seguridad.

Con PTP 2.1 también hay que verificar domainNumber y sdoId. Las recomendaciones iniciales son 123 y 0. El dominio puede configurarse si existe conflicto, siempre que todos los participantes que deban comunicarse compartan la pareja.

Un dominio correcto prueba pertenencia a una conversación configurada. No demuestra que el reloj remoto sea exacto ni que deba ganar frente a otras fuentes NTP.

Cómo aceptar una corrección que no tiene firma

Un reloj transparente one-step E2E escribe su retardo de reenvío en el correction field del evento PTP. Para corregir el intercambio NTP, el cliente necesita la ida y la vuelta. La respuesta lleva su propia corrección en la cabecera; la corrección acumulada por la solicitud vuelve en el nuevo campo NTP Network Correction, tipo 0x010A.

El servidor debe ignorar el valor de corrección que reciba en la solicitud. El cliente debería enviarlo a cero. Con ambos datos puede corregir peer delay y offset, incorporando la duración de recepción y un margen por error de frecuencia de los relojes transparentes.

La validación impide que la fórmula se convierta en obediencia. Si el retardo corregido, la corrección de solicitud o la de respuesta es negativa, la muestra no se acepta para sincronización. El root delay no se corrige, de modo que root distance continúa expresando un error máximo independiente de las correcciones de red.

Además, las correcciones de los relojes transparentes no son autenticables. Un atacante en ruta puede alterarlas. Solo se aceptan correcciones inferiores al retardo medido; el RFC equipara el efecto restante al de retrasar un paquete NTP intacto. Hay una frontera cuantitativa, no una garantía de origen.

NTP sigue decidiendo entre fuentes

NTP compara servidores, filtra muestras, detecta fuentes fallidas y disciplina el reloj local. El transporte PTP acerca algunos sellos al medio físico y añade evidencia sobre tránsito. No desplaza esas decisiones a la red intermedia.

Un equipo puede incluso sincronizarse por PTP en un dominio y transportar NTP en otro. NTP over PTP no exige que haya otros relojes PTP. Si existen relojes transparentes compatibles, sus correcciones se aprovechan; si no, el sello de hardware de la NIC puede seguir siendo útil.

El resultado es una extensión acotada del código operativo. Se normaliza lo mínimo para interoperar y cada operador conserva la decisión futura de adoptarlo. Una herramienta de medida entra en el sistema sin recibir mandato sobre la fuente que soportará las consecuencias.

Fuentes