RFC 10030

Network Time Protocol (NTP) over the Precision Time Protocol (PTP)

📅 published August 2026, from ietf

Network Time Protocol (NTP) over the Precision Time Protocol (PTP) 💖

okay bestie, this is RFC 10030 🎀 It's a Standards Track document from the Internet Engineering Task Force (IETF), written by M. Lichvar from Red Hat. It was published in August 2026 and has ISSN 2070-1721. Nothing is listed as obsoleting or updating anything, so it's not replacing or patching an older RFC 🦋

Abstract ✨

okay so this doc is a transport for the client-server and symmetric modes of the Network Time Protocol (NTP). It wraps NTP messages inside messages of the Precision Time Protocol (PTP) 🧚 Why? Because it makes hardware timestamping work on network interface controllers (NICs) that can only timestamp PTP messages, and it also handles delay corrections in PTP transparent clocks. iconic, honestly 👑

Status of This Memo 🌸

this one is an Internet Standards Track document, so it's officially the real deal 🫶 It comes from the IETF, represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check out Section 2 of RFC 7841. info about the current status, errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc10030 💅

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 🔥

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. go read those, because they spell out your rights and restrictions for this doc 🙈 also, any Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions. they come with no warranty, as described in the Revised BSD License.

Table of Contents 🧚

1.  Introduction
  1.1.  Comparison with PTP
  1.2.  Requirements Language
2.  PTP Transport for NTP
3.  Network Correction Extension Field
4.  IANA Considerations
  4.1.  New IANA PTP TLV Subtypes Registry
  4.2.  NTP Extension Field Registration
5.  Security Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Author's Address

1. Introduction 🦋

okay so PTP [IEEE1588-2019] was built for super accurate clock sync on local networks. the big secret is that it leans on hardware timestamping in every network device involved (NICs, switches, routers, all of them!) so software, processing, and queueing delays don't mess up the offset and delay measurements 💜

PTP was first designed for multicast. later on, unicast messaging was added, which is super useful in bigger networks where only some devices along the path support PTP. telecom profiles like G.8265.1 [G8265-1] and G.8275.2 [G8275-2] are examples of that 🌸

NTP [RFC5905] doesn't need hardware timestamping. but if an implementation has it, it can use it to dodge software, processing, and queueing delays, just like PTP does ✨ if you compare PTP with NTP's timing modes, PTP is functionally closest to NTP's broadcast mode 🍓

here's the issue for NTP 😭 some hardware can only timestamp PTP packets. that's because of how the hardware is designed. it can only give receive timestamps at a limited rate, not at the max rate the network link could handle. so, to avoid missing receive timestamps when the interface is slammed with other traffic, the hardware has a filter that checks each packet and only captures a timestamp for the packets that actually need one 🎀

the hardware filter can usually be set up for specific PTP transports (UDP over IPv4, UDP over IPv6, and 802.3). sometimes it can even target a specific PTP message type, like sync or delay request, to cut down the timestamping rate on the server or client in multicast messaging. BUT it typically can't be configured to timestamp NTP messages sent to UDP port 123 🥲

another issue for NTP is missing hardware support in switches and routers. with PTP, these devices act as either boundary clocks or transparent clocks. boundary clocks are like NTP clients that also work as servers for other clients 🧚 transparent clocks are way simpler. they just measure how long it takes to forward a PTP packet and write that delay into the correction field, either in the packet itself (one-step mode) or in a later packet in the exchange (two-step mode). transparent clocks are specific to whichever PTP delay mechanism the network uses, either end to end (E2E) or peer to peer (P2P) 💅

so this doc adds a brand new transport for NTP that enables hardware timestamping on NICs that can only timestamp PTP messages. it also takes advantage of one-step E2E PTP unicast transparent clocks 👑 it adds a new type-length-value (TLV) for PTP to carry NTP messages, plus a new extension field for NTP so clients and peers can get the correction for their NTP requests from transparent clocks. and yes, the NTP broadcast mode is NOT supported here 🙈

PTP messages have to follow the protocol rules of IEEE 1588 [IEEE1588-2019]. the good news is NTP over PTP doesn't require other PTP clocks to be in the network, and it won't disrupt them if they are there ✨

if the network uses one-step E2E transparent clocks, NTP clients and peers using PTP as transport can reach the same or better accuracy than PTP clocks using PTP for sync. and hosts can use PTP for synchronization in one domain while transporting NTP messages in another domain at the same time. the main character multitasking energy is real 🌈

1.1. Comparison with PTP 💖

the client-server mode of NTP has several advantages over PTP using multicast or unicast messaging, even when NTP uses the PTP transport:

  • NTP is more secure. existing security mechanisms for NTP, like Network Time Security [RFC8915], still work over the PTP transport. PTP is harder to protect against delay attacks because its sync message isn't an immediate response to a client request. the PTP unicast mode allows almost-infinite traffic amplification, which can be exploited for denial-of-service attacks. the only way to limit that is with security mechanisms that require client authentication 🔥
  • NTP is more resilient to failures. each client can use multiple servers and detect failed sources during source selection. in PTP, a single hardware or software failure can disrupt the whole PTP domain. to handle any failure, you have to use multiple independent domains 🫶
  • NTP is better suited for networks that don't have full on-path PTP support, or where timestamping errors aren't distributed symmetrically (for example, when they're sensitive to network load). NTP doesn't assume network delay is constant, and it doesn't assume the rate of measurements in opposite directions is symmetric. it can filter measurements more effectively and isn't sensitive to asymmetrically distributed network delays and timestamping errors. PTP has to measure offset and delay separately to enable multicast messaging, and that's needed to reduce the transmit timestamping rate 🦋
  • NTP needs fewer messages to get the same number of timestamps, so it uses less network bandwidth than PTP using unicast messaging 🍓
  • NTP gives clients an estimate of the maximum error of the clock, called root distance ✨

the downside of NTP is that the transmit timestamping rate goes up as the number of clients grows. a server limited by its hardware timestamping rate can't give the same number of clients a highly accurate time service the way PTP with multicast messaging can 😭

1.2. Requirements Language 💅

okay, now the serious caps-lock stuff 🎀 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🫶

2. PTP Transport for NTP 🎀

Okay so bestie, this is where NTP gets to ride along on PTP 🚀. A brand-new TLV is defined so PTP can carry NTP messages in client (3), server (4), and symmetric (1 and 2) modes (see [RFC5905]) 💖. Other NTP modes inside the TLV? Not specified, so don't even go there 🙈. Any PTP transport that does unicast messaging and has an IPv4 or IPv6 mapping can carry NTP over PTP ✨.

The NTP TLV MUST be included in a unicast PTP event message 📮. The event message is needed to switch on PTP-specific hardware timestamping and transparent clock corrections 🔥. The PTP message MUST conform to PTP version 2 [IEEE1588-2008], PTP version 2.1 [IEEE1588-2019], or any future version of the PTP specification that allows the NTP TLV to be included as an organization-specific TLV 👑.

The NTP TLV is an organization-specific TLV with these fields (octets in network order) 🧚:

  • type is 0x8000 (ORGANIZATION_EXTENSION_DO_NOT_PROPAGATE) in PTP version 2.1 or 0x0003 (ORGANIZATION_EXTENSION) in PTP version 2
  • lengthField is 8 + the length of the NTP message
  • organizationId is 00-00-5E (the Organizationally Unique Identifier (OUI) is assigned to IANA by the IEEE Registration Authority)
  • organizationSubType is 0x1
  • dataField holds two zero octets for 32-bit alignment, followed by the NTP message, which would normally be the UDP payload

An NTP client or peer using the PTP transport sends its NTP requests packed as the NTP TLV inside PTP messages 📦.

An NTP server or peer that gets an NTP request over the PTP transport MUST form its response as the NTP TLV using that same PTP transport 🙌. To avoid traffic amplification, the server or peer MUST NOT send the response if the PTP message holding the NTP response is longer than the PTP message holding the NTP request 🛑. This requirement hits Autokey [RFC5906] hard, because some responses are longer than the requests (for example, during certificate exchange) 😭. The request SHOULD be padded with the PTP PAD TLV (type 0x8008) up to the maximum expected length of the response, so the response can actually get through 🧸.

If the NTP response is going to be used for synchronization (so it's not an error message), the PTP message holding that response SHOULD be the same length as the PTP message holding the request. Use the PTP PAD TLV if needed, so you don't get an asymmetric delay in networks without full on-path PTP support 💅.

The PTP version 2.1 [IEEE1588-2019] specification says this:

A domain shall define the scope of PTP message communication, state, operations, data sets, and timescale. Within a PTP Network, a domain is identified by two attributes: domainNumber and sdoId.

So for NTP over PTP version 2.1, the NTP servers, clients, and peers MUST verify that received PTP messages have the domainNumber and sdoId that NTP over PTP is expected to use on the network 🔍. The domainNumber SHOULD be 123 by default, and sdoId SHOULD be 0 🌸. Number 123 isn't commonly used by PTP profiles, so it's less likely to clash with some other PTP operation running on the network 🦋. The domainNumber SHOULD be configurable, so you can move NTP over PTP to another domain if it collides with a PTP profile using that same domainNumber and sdoId 🔧. Just remember that every server, client, and peer using NTP over PTP on the network needs the same domainNumber and sdoId to talk to each other 🫶.

If UDP is the transport for PTP, the UDP source and destination port numbers SHOULD be the PTP event port (319) 🌈. If the client implemented port randomization [RFC9109], requests and/or responses would not get a hardware receive timestamp, because the hardware filter only matches the PTP event port 🙈.

Any authenticator fields in the NTP messages MUST be calculated only over the NTP message that follows the NTP TLV header 🔐. Other data in the PTP message (outside the NTP TLV) is not protected. Apart from the PTP correction field, which gets special handling in the next section, the other PTP fields are only there to transport the NTP message and have no impact on NTP security, kind of like the IP and UDP headers 💜.

Receive and transmit timestamps in the NTP messages SHOULD NOT be adjusted for where the NTP data begins in the PTP message ⏱️. To keep link speeds from messing with accuracy in networks without full on-path PTP support, the transmit timestamp SHOULD match the PTP message timestamp point (the beginning of the first symbol after the Ethernet start of frame delimiter). The receive timestamp SHOULD be moved from the PTP message timestamp point to the end of reception (for example, the end of the last symbol of the Ethernet frame check sequence) ✨.

3. Network Correction Extension Field 🦋

Okay, so one-step E2E PTP transparent clocks change the correction field in the header of PTP event messages that carry NTP messages 🔄. To verify and apply corrections to an NTP measurement, the client or peer needs the correction for both the request and the response 🧠. The response's correction is already in the PTP header of the message itself. The request's correction comes from the server or other peer, in a new NTP extension field included in the response 💌.

The Network Correction Extension Field looks like this (Figure 1) 👀:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type = 0x010A         |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  Network Correction (64 bits)                 +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            Padding                            .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Format of Network Correction Extension Field

The padding length is the minimum needed to make a valid extension field in the NTP version being used. In NTPv4 that's 16 octets, which gives you a 28-octet extension field conforming to [RFC7822] 📏.

The Network Correction field uses the 64-bit NTP timestamp format (resolution of about 1/4th of a nanosecond) 🔬. The PTP header's correction field is a different format: 64-bit nanoseconds + 16-bit fraction 🤓.

The NTP network correction is the sum of the PTP corrections added by transparent clocks, plus the time it takes to receive the packet (packet length including the frame check sequence, divided by the link speed) ➕.

Why not just use the PTP correction? To avoid an asymmetric correction when the server and client (or peers) are connected with different link speeds 🙅‍♀️. The receive duration in the NTP correction cancels out the shift from the PTP receive timestamp (the beginning of reception) to the NTP receive timestamp (the end of reception) 🪄.

Figure 2 shows the NTP timestamps, transmit/receive durations, and the processing and queuing delays included in PTP corrections for an NTP exchange over two PTP transparent clocks 🗺️. The link speed goes up along the path from client to server. Propagation delays in cables aren't shown 🔌.

   NTP server                          T2  T3
                --------------------|==|----|==|--------------------
   PTP TC #2                      |~|          |~|
                             |====|              |====|
   PTP TC #1               |~|                        |~|
                --|========|----------------------------|========|--
   NTP client    T1                                              T4

   PTP correction |========|~|====|~|       |==|~|====|~|
   NTP correction |========|~|====|~|==|    |==|~|====|~|========|

Figure 2: PTP Versus NTP Correction

When an NTP server that supports the PTP transport gets an NTP request containing the Network Correction Extension Field, it SHOULD respond with the extension field giving the network correction of the client's request 🎁. The server MUST ignore the network correction value in the request 🙈.

An NTP client or peer that supports the PTP transport and is set up to use the network correction for the association SHOULD include the extension field in its NTP requests 💫. For a client, the correction value in the extension field SHOULD always be zero 0️⃣.

Once the client or peer has the network correction of both the request and the response, it can correct the measured NTP peer delay and offset 🧮:

  • delta_c = delta - (nc_rs + nc_rq - dur_rs - dur_rq) * (1 - freq_tc)
  • theta_c = theta + (nc_rs - nc_rq) / 2

where:

  • delta is the NTP peer delay from [RFC5905]
  • theta is the NTP offset from [RFC5905]
  • nc_rq is the network correction of the request
  • nc_rs is the network correction of the response
  • dur_rq is the transmit duration of the request
  • dur_rs is the receive duration of the response
  • freq_tc is the maximum assumed frequency error of transparent clocks

The corrected delay (delta_c) and offset (theta_c) MUST NOT be accepted for synchronization if any of delta_c, nc_rs, and nc_rq is negative 🚫. This requirement limits the error caused by faulty transparent clocks and on-path attackers 🛡️.

Root delay (DELTA) MUST NOT be corrected, so the maximum assumed error (root distance) stays independent of network corrections 🙅‍♀️.

Scaling by the freq_tc constant (for example, 100 parts per million (ppm)) makes room for errors in corrections made by transparent clocks running faster than true time 🏃‍♀️. It also stops samples with larger corrections from ending up with a shorter delay than samples with smaller corrections, which would hurt their filtering and weighting 🧁.

The dur_rq and dur_rs values make the corrected peer delay match a direct connection to the server 🔗. Without them, a perfectly corrected delay on a short network path would be too close to zero, and often negative, because of frequency offset between client and server 😵. NTP peers and PTP clocks using the E2E delay mechanism are more sensitive to frequency offsets because their measurement intervals are longer 📈. If dur_rq is unknown, it MAY be assumed to be equal to dur_rs 🤷‍♀️.

4. IANA Considerations 💖

4.1. New IANA PTP TLV Subtypes Registry 🦋

okay bestie, so IANA made a brand new registry called "IANA PTP TLV Subtypes" 💅 It lives under the "IANA OUI Ethernet Numbers" registry group, and it's for organizationSubType values of PTP TLVs that use 00-00-5E as the organizationId. (That's the OUI assigned to IANA by the IEEE Registration Authority, iykyk ✨)

Every entry in the registry has three fields, and they are REQUIRED 🔥:

  • Subtype: An integer in the range 0-0xFFFFFF
  • Description: A short text description
  • Reference: A reference to a document describing the IANA PTP TLV

The subtype range is split into three ranges, and each one has its own allocation policy 🌈:

  • 0-0xFFFF: IETF Review
  • 0x10000-0x7FFFFF: Specification Required
  • 0x800000-0xFFFFFE: Experimental and Private Use

The initial contents of the registry look like this 🍓:

     +===================+===============================+===========+
     | Subtype           | Description                   | Reference |
     +===================+===============================+===========+
     | 0x0               | Reserved                      | RFC 10030 |
     +-------------------+-------------------------------+-----------+
     | 0x1               | Network Time Protocol Message | RFC 10030 |
     +-------------------+-------------------------------+-----------+
     | 0x2-0x7FFFFF      | Unassigned                    |           |
     +-------------------+-------------------------------+-----------+
     | 0x800000-0xFFFFFE | Reserved for Experimental and | RFC 10030 |
     |                   | Private Use                   |           |
     +-------------------+-------------------------------+-----------+
     | 0xFFFFFF          | Reserved                      | RFC 10030 |
     +-------------------+-------------------------------+-----------+

Table 1

Changes in the Specification Required range get the green light from a designated expert (DE) 🧐. The DE should be familiar with [RFC8126] (particularly Section 5 of [RFC8126]) and the current PTP specifications. The DE should verify that the specification of the organization-specific TLV identified by the assigned subtype exists and is publicly available. The purpose and use of the TLV should be sufficiently clear to enable interoperating implementations, without harming the protocol or the ecosystem 💖

4.2. NTP Extension Field Registration 🧚

IANA allocated the following field in the "NTP Extension Field Types" registry <https://www.iana.org/assignments/ntp-parameters/> defined by [RFC5905] 🌸

+============+====================+===========+
| Field Type | Meaning            | Reference |
+============+====================+===========+
| 0x010A     | Network Correction | RFC 10030 |
+------------+--------------------+-----------+

Table 2

5. Security Considerations 💀

okay this part is seriously important, so read it with me 🫶 PTP transport stops NTP clients from randomizing their source port, as described in [RFC9109]. Why? Because both requests and responses have to be sent to the PTP port, so the client can get a hardware receive timestamp and corrections from PTP transparent clocks.

The corrections provided by PTP transparent clocks cannot be authenticated 🚨 On-path attackers can modify the correction field, but clients only accept corrections smaller than the measured delay. The impact is comparable to the impact of delaying unmodified NTP messages.

6. References 📚

6.1. Normative References

6.2. Informative References

Acknowledgements 🫶

Huge shoutout to Doug Arnold, Rodney Cummings, Martin Langer, and Robert Sparks for their comments and suggestions 🙌 The author would like to thank them all, and they absolutely deserve it ✨

Author's Address 🎀

  • Miroslav Lichvar
  • Red Hat
  • Email: mlichvar@redhat.com
📦 where this page comes from