Summary

  • Published in August 2026, RFC 10030 carries NTP client/server and symmetric-mode messages inside unicast PTP event messages so NTP can use PTP-only NIC hardware timestamping and compatible transparent-clock corrections.
  • The transport deliberately stops short of transferring authority: PTP corrections are unauthenticated, negative corrected values are rejected, root delay is not corrected, and NTP retains source selection, Network Time Security and its own error accounting.

The same exchange, a different measurement surface

The hardware problem is specific. Many network interface controllers can place a receive timestamp close to the physical arrival of a PTP packet, but cannot do the same for an ordinary NTP packet sent to UDP port 123. Their filters are designed to recognise a limited class of PTP traffic so timestamping capacity is not consumed by every frame at line rate.

RFC 10030 does not replace NTP with PTP. It defines a container. NTP client, server and symmetric messages sit in a new organization-specific TLV carried by a unicast PTP event message. Event messages matter because they are the messages for which PTP hardware timestamps and transparent-clock corrections exist. Broadcast-mode NTP is outside the specification.

The assignment is concrete. The TLV uses IANA's organizational identifier 00-00-5E, with organization subtype 0x1 registered for a Network Time Protocol Message. The final RFC was published in August 2026 after the Network Time Protocols Working Group process; the RFC Editor announcement on 14 August identifies Miroslav Lichvar as author and draft-ietf-ntp-over-ptp-08 as the final draft tag.

The new envelope leaves the inner exchange recognizable. A server that receives an NTP request through the PTP transport must send its response through the same transport. NTP authenticators are calculated over the NTP message inside the TLV, not over the rest of the PTP message. Network Time Security can still protect the NTP protocol exchange. None of this turns the outer header into an authenticated statement of time.

Port 319 buys a timestamp and spends randomisation

When UDP carries PTP, RFC 10030 says source and destination should use PTP event port 319. That allows a NIC filter looking for the PTP event port to produce hardware receive timestamps. It also exposes a trade-off: the client cannot use the NTP source-port randomisation described in RFC 9109 and still expect that port-specific hardware filter to match.

The document states the loss rather than hiding it. A deployment gains a measurement capability and gives up one form of packet-demultiplexing unpredictability. NTS still works, but “NTS works” must not be expanded into “every outer field is authenticated.” The right operational question is not whether the new transport is simply more secure. It is whether the accuracy benefit, the fixed-port exposure and the local security controls form an acceptable bundle for this network.

The PTP domain also remains an explicit scope boundary. With PTP version 2.1, participants must verify the expected domainNumber and sdoId. The recommended defaults are domain 123 and sdoId 0, chosen to reduce collision with common PTP profiles, but the domain can be configured. Every NTP-over-PTP participant that must communicate needs the same tuple.

That tuple routes a protocol conversation. It does not certify the quality of the upstream clock. A correctly scoped packet can still carry a poor NTP sample; a precisely timestamped response can still come from a source the client's selection logic should reject.

The correction has a ceiling but no signature

One-step end-to-end PTP transparent clocks can write measured forwarding delay into the PTP correction field as an event message crosses the network. An NTP client needs corrections for both directions. The response already carries its own PTP correction; RFC 10030 therefore defines an NTP Network Correction extension field, type 0x010A, so the server can return the correction accumulated by the request.

The server must ignore any correction value supplied by the requester. A client that asks for the extension should put zero in its request. Once both values are available, the client can adjust measured peer delay and offset while accounting for packet receive duration and an assumed frequency error in the transparent clocks.

The acceptance rules reveal the limit of the mechanism. The client must reject the corrected result if corrected delay, request correction or response correction is negative. Root delay must not be corrected, so root distance remains a maximum assumed error independent of the network corrections. The path can refine one measurement without rewriting the client's statement about worst-case distance from its reference.

Most importantly, transparent-clock corrections cannot be authenticated. An on-path attacker can modify the PTP correction field. The protocol bounds what will be accepted: corrections smaller than measured delay can affect the result, and the RFC compares the residual attack with delaying an unmodified NTP packet. A bound is not a signature. It limits power without pretending to establish provenance.

Precision is evidence, not a verdict

NTP already treats a timestamp exchange as evidence to be filtered, compared and disciplined locally. It can use multiple servers, reject failed or inconsistent sources and maintain an estimate of root distance. PTP transport improves where some timestamps are taken and lets compatible network devices contribute delay measurements. It does not move the source-selection algorithm into those devices.

This distinction separates the new article from a general history of NTP. The issue is not how four timestamps create an offset and delay estimate, nor how several fallible peers can be compared. The new event is the addition of a measurement surface beneath that existing decision system.

The architecture is deliberately composable. A host may use PTP itself for clock synchronisation in one domain while using a separate domain to carry NTP. NTP over PTP does not require other PTP clocks to exist. Where one-step E2E transparent clocks do exist, their corrections can improve measurements. Where they do not, the event-message carriage can still expose NIC timestamping.

Minimum rules around a useful retrofit

Several requirements keep the retrofit narrow. A response must not be longer than its request, limiting amplification. A requester expecting a larger response can pad its message. A synchronisation response should be the same length as the request, because unequal packet lengths can introduce asymmetric delay on a path without complete PTP support.

The wire contract is therefore more than “put NTP inside PTP.” It specifies message modes, unicast carriage, domain scope, port behaviour, authentication coverage, response sizing, timestamp points, correction return and rejection conditions. These are the minimum shared facts implementations need in order to interoperate without inventing authority that the transport never received.

That is also the economic virtue of the design. Existing timing-capable hardware can become useful to NTP without forcing operators to replace source-selection logic, security associations or the higher-level clock discipline that already works. The standard localises the new decision: enable the transport where the hardware and path justify it, and leave future adoption voluntary elsewhere.

Sources