View source for Network Time Protocol

{{Short description|Networking protocol for clock synchronization}}
{{Distinguish|Daytime Protocol|Time Protocol|NNTP}}
{{Use dmy dates|date=January 2025}}
{{Infobox protocol
| name        = Network Time Protocol
| image       = Network_Time_Protocol_servers_and_clients.svg
| caption     = 
| standard    = {{IETF RFC|5905}}
| developer   = [[David L. Mills]], Harlan Stenn, Network Time Foundation <!--organization(s) involved in development-->
| introdate   = {{Start date and age|1985}} <!--{{Start date|YYYY|MM|DD}}-->
| industry    = <!--industries used (such as PC/Chemical/Multimedia)-->
| connector   = <!--connector(s) usable with protocol-->
| hardware    = <!--examples of compatible hardware-->
| range       = <!--{{convert|X|mi|abbr=on}}-->
| newer       = <!--superseded by which protocol-->
| website     = <!--URL to specs; OD wrap in template -->
}}

{{IPstack}}

The '''Network Time Protocol''' ('''NTP''') is a [[networking protocol]] for [[clock synchronization]] between computer systems over [[packet-switched]], variable-[[Network latency|latency]] data networks. In operation since before 1985, NTP is one of the oldest Internet protocols in current use. NTP was designed by [[David L. Mills]] of the [[University of Delaware]].

NTP is intended to [[synchronize]] participating computers to within a few [[millisecond]]s of [[Coordinated Universal Time]] (UTC).<ref name="Mills2010" />{{rp|3}} It uses the [[intersection algorithm]], a modified version of [[Marzullo's algorithm]], to select accurate [[time server]]s and is designed to mitigate the effects of variable [[network latency]]. NTP can usually maintain time to within tens of milliseconds over the public [[Internet]], and can achieve better than one millisecond accuracy in [[local area network]]s under ideal conditions. Asymmetric [[Routing|routes]] and [[network congestion]] can cause errors of 100&nbsp;ms or more.<ref name="summary">{{cite web |url=http://www.eecis.udel.edu/~mills/exec.html |title=Executive Summary: Computer Network Time Synchronization |access-date=2011-11-21 |archive-url=https://web.archive.org/web/20111102204926/http://www.eecis.udel.edu/~mills/exec.html |archive-date=2011-11-02 |url-status=live}}</ref><ref name="faq">{{cite web |url=http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK |title=NTP FAQ |publisher=The NTP Project |access-date=2011-08-27 |archive-url=https://web.archive.org/web/20110906014530/http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK |archive-date=2011-09-06 |url-status=live}}</ref>

The protocol is usually described in terms of a [[client–server model]], but can as easily be used in [[peer-to-peer]] relationships where both peers consider the other to be a potential time source.<ref name="Mills2010" />{{Rp|20}} Implementations send and receive [[timestamp]]s using the [[User Datagram Protocol]] (UDP); the service is normally on [[port number]] 123, and in some modes both sides use this port number.<ref name="qNvGW">{{cite web |url= https://www.iana.org/assignments/port-numbers |title= Port Numbers |publisher= The Internet Assigned Numbers Authority (IANA) |access-date= 2011-01-19 |archive-url= https://web.archive.org/web/20010604223215/https://www.iana.org/assignments/port-numbers |archive-date= 2001-06-04 |url-status= live}}</ref>{{Ref RFC|5905|rp=16}} They can also use [[Broadcasting (networking)|broadcasting]] or [[multicasting]], where clients passively listen to time updates after an initial round-trip calibrating exchange.<ref name="faq" /> NTP supplies a warning of any impending [[leap second]] adjustment, but no information about local [[time zone]]s or [[daylight saving time]] is transmitted.<ref name="summary" /><ref name="faq" />

The current protocol is version 4 (NTPv4),{{Ref RFC|5905}} which is [[backward compatible]] with version 3.{{Ref RFC|1305}}

== Clock synchronization algorithm ==
[[File:NTP-Algorithm.svg|thumb|Round-trip delay time δ]]

A typical NTP client regularly [[Polling (computer science)|polls]] one or more NTP servers. The client must compute its time offset and [[round-trip delay]]. Time offset ''θ'' is the positive or negative (client time > server time) difference in absolute time between the two clocks. It is defined by

<math display="block">\theta = \frac{(t_1 - t_0) + (t_2 - t_3 )}{2} ,</math>
and the round-trip delay ''δ'' by
<math display="block">\delta = {(t_3 - t_0 ) - ( t_2- t_1 )} ,</math>
where
*''t''<sub>0</sub> is the client's timestamp of the request packet transmission,
*''t''<sub>1</sub> is the server's timestamp of the request packet reception,
*''t''<sub>2</sub> is the server's timestamp of the response packet transmission and
*''t''<sub>3</sub> is the client's timestamp of the response packet reception.<ref name="Mills2010" />{{rp|19}}

To derive the expression for the offset, note that for the request packet,
<math display="block">t_0 + \theta + \delta/2 = t_1</math>
and for the response packet,
<math display="block">t_3 + \theta - \delta/2 = t_2</math>
Solving for ''θ'' yields the definition of the time offset.

The values for ''θ'' and ''δ'' are passed through filters and subjected to statistical analysis ("mitigation"). [[Outlier]]s are discarded and an estimate of time offset is derived from the best three remaining candidates. The clock frequency is then adjusted to reduce the offset gradually ("discipline"), creating a [[feedback loop]].<ref name="Mills2010">{{cite book|author=David L. Mills|title=Computer Network Time Synchronization: The Network Time Protocol|url=https://books.google.com/books?id=pdTcJBfnbq8C&pg=PA12|date=12 December 2010|publisher=Taylor & Francis|isbn=978-0-8493-5805-0|pages=12–|access-date=16 October 2016|archive-url=https://web.archive.org/web/20140718092324/http://books.google.com/books?id=pdTcJBfnbq8C&pg=PA12|archive-date=18 July 2014|url-status=live}}</ref>{{rp|20}}

Accurate synchronization is achieved when both the incoming and outgoing routes between the client and the server have symmetrical nominal delay. If the routes do not have a common nominal delay, a [[systematic bias]] exists of half the difference between the forward and backward travel times. A number of approaches have been proposed to measure asymmetry,<ref name="iL6pp">{{cite conference |last1=Gotoh |first1=T. |last2=Imamura |first2=K. |last3=Kaneko |first3=A. |title=Conference Digest Conference on Precision Electromagnetic Measurements |chapter=Improvement of NTP time offset under the asymmetric network with double packets method |conference=Conference on Precision Electromagnetic Measurements |pages=448–449 |year=2002 |doi=10.1109/CPEM.2002.1034915 |isbn=0-7803-7242-5}}</ref> but among practical implementations only chrony seems to have one included.<ref name="Ocilw"/><ref>{{cite web |title=sourcestats.c, function estimate_asymmetry() |url=https://git.tuxfamily.org/chrony/chrony.git/tree/sourcestats.c?h=4.3 |website=git.tuxfamily.org (chrony)}}</ref>

== History ==
[[File:DL Mills-2.jpg|thumb|upright|NTP was designed by [[David L. Mills]].]]
{{Graphical timeline
|title=[[Request for Comments|RFC]] evolution for NTP
|align=right
|plot-colour=#bbeebb
|from=1980
|to=2023
|scale-increment=5
|width=18
|height=500
|height-unit=px
|bar1-text={{nowrap|v0, RFC&nbsp;958}}{{Ref RFC|958}}
 |bar1-from=1985 | bar1-to=1988 | bar1-left=0.05 | bar1-right=0.45
|bar2-text={{nowrap|v1, RFC&nbsp;1059}}{{Ref RFC|1059}}
 |bar2-from=1988 | bar2-to=1989 | bar2-left=0.05 | bar2-right=0.45
|bar3-text={{nowrap|v2, RFC&nbsp;1119}}{{Ref RFC|1119}}
 |bar3-from=1989 | bar3-to=1992 | bar3-left=0.05 | bar3-right=0.45
|bar4-text={{nowrap|v3, RFC&nbsp;1305}}{{Ref RFC|1305}}
 |bar4-from=1992 | bar4-to=2010 | bar4-left=0.05 | bar4-right=0.45
|bar5-text={{nowrap|v4, RFC&nbsp;5905}}{{Ref RFC|5905}}
 |bar5-from=2010 | bar5-to=2023 | bar5-left=0.05 | bar5-right=0.95
|bar7-text ={{nowrap|v3, RFC&nbsp;1361}}{{Ref RFC|1361}}
 |bar7-from=1992  | bar7-to=1995  | bar7-left=0.55  |bar7-right=0.95
|bar8-text ={{nowrap|v3, RFC&nbsp;1769}}{{Ref RFC|1769}}
 |bar8-from=1995  | bar8-to=1996  | bar8-left=0.55  |bar8-right=0.95
|bar9-text ={{nowrap|v4, RFC&nbsp;2030}}{{Ref RFC|2030}}
 |bar9-from=1996  | bar9-to=2006  | bar9-left=0.55  |bar9-right=0.95
|bar10-text={{nowrap|v4, RFC&nbsp;4330}}{{Ref RFC|4330}}
 |bar10-from=2006 | bar10-to=2010 | bar10-left=0.55 |bar10-right=0.95
|note1=DCNET Internet Clock Service{{Ref RFC|778}} | note1-at=1981 | note1-colour=green
|note2=SNTP | note2-at=1992 | note2-colour=blue
|note3=SNTP merged |note3-at=2010 |note3-colour=blue
|note4=Ext. fields{{Ref RFC|7822}}|note4-at=2016|note4-colour=red
|note5=[[Message authentication code|MAC]] change{{Ref RFC|8573}}|note5-at=2019|note5-colour=red
|note6=Port randomization{{Ref RFC|9109}}|note6-at=2021|note6-colour=red
}}

In 1979, network [[time synchronization]] technology was used in what was possibly the first public demonstration of [[Internet]] services running over a trans-Atlantic satellite network, at the [[National Computer Conference]] in New York. The technology was later described in the 1981 Internet Engineering Note (IEN) 173<ref name="ND7CF">{{citation |url=http://www.cis.ohio-state.edu/htbin/ien/ien173.html |archive-url=https://web.archive.org/web/19961230073104/http://www.cis.ohio-state.edu/htbin/ien/ien173.html |archive-date=1996-12-30 |title=Time Synchronization in DCNET Hosts |author=D.L. Mills |date=25 February 1981}}</ref> and a public protocol was developed from it that was documented in {{IETF RFC|778}}. The technology was first deployed in a local area network as part of the Hello routing protocol and implemented in the [[Fuzzball router]], an experimental operating system used in network prototyping, where it ran for many years.

Other related network tools were available both then and now. They include the [[Daytime Protocol|Daytime]] and [[Time Protocol|Time]] protocols for recording the time of events, as well as the [[ICMP Timestamp]] messages and IP Timestamp option ({{IETF RFC|781}}). More complete synchronization systems, although lacking NTP's data analysis and clock disciplining algorithms, include the [[Unix]] daemon ''[[timed]]'', which uses an election algorithm to appoint a server for all the clients;<ref name="Y8SkT">{{citation |url=http://www.skrenta.com/rt/man/timed.8.html |title=TIMED(8) |work=UNIX System Manager's Manual |access-date=2017-09-12 |archive-url=https://web.archive.org/web/20110722012159/http://www.skrenta.com/rt/man/timed.8.html |archive-date=2011-07-22 |url-status=live}}</ref> and the '''Digital Time Synchronization Service''' (DTSS), which uses a hierarchy of servers similar to the NTP stratum model.

In 1985, NTP version 0 (NTPv0) was implemented in both Fuzzball and Unix, and the NTP packet header and [[round-trip delay]] and offset calculations, which have persisted into NTPv4, were documented in {{IETF RFC|958}}. Despite the relatively slow computers and networks available at the time, accuracy of better than 100 [[millisecond]]s was usually obtained on Atlantic spanning links, with accuracy of tens of milliseconds on [[Ethernet]] networks.

In 1988, a much more complete specification of the NTPv1 protocol, with associated algorithms, was published in {{IETF RFC|1059}}. It drew on the experimental results and clock filter algorithm documented in {{IETF RFC|956}} and was the first version to describe the [[client–server]] and [[peer-to-peer]] modes. In 1991, the NTPv1 architecture, protocol and algorithms were brought to the attention of a wider engineering community with the publication of an article by [[David L. Mills]] in the ''[[IEEE Transactions on Communications]]''.<ref name="AMYJK">{{Cite journal |title=Internet Time Synchronization: The Network Time Protocol |journal=IEEE Transactions on Communications |date=October 1991 |volume=39 |pages=1482–1493 |number=10 |url=http://www3.cs.stonybrook.edu/~jgao/CSE590-spring11/91-ntp.pdf |url-access=limited |author=David L. Mills |doi=10.1109/26.103043 |bibcode=1991ITCom..39.1482M |access-date=2017-11-06 |archive-url=https://web.archive.org/web/20160610113047/http://www3.cs.stonybrook.edu/%7Ejgao/CSE590-spring11/91-ntp.pdf |archive-date=2016-06-10 |url-status=live}}</ref>

In 1989, {{IETF RFC|1119}} was published defining NTPv2 by means of a [[state machine]], with [[pseudocode]] to describe its operation. It introduced a management protocol and [[Digital signature|cryptographic authentication]] scheme which have both survived into NTPv4, along with the bulk of the algorithm. However the design of NTPv2 was criticized for lacking [[Correctness (computer science)|formal correctness]] by the DTSS community, and the clock selection procedure was modified to incorporate [[Marzullo's algorithm]] for NTPv3 onwards.{{Ref RFC|1305|notes=no|quote=The clock-selection procedure was modified to remove the first of the two sorting/discarding steps and replace with an algorithm first proposed by Marzullo and later incorporated in the Digital Time Service. These changes do not significantly affect the ordinary operation of or compatibility with various versions of NTP, but they do provide the basis for formal statements of correctness.}}

In 1992, {{IETF RFC|1305}} defined NTPv3. The RFC included an analysis of all sources of error, from the [[Master clock|reference clock]] down to the final client, which enabled the calculation of a [[Software metric|metric]] that helps choose the best server where several candidates appear to disagree. Broadcast mode was introduced.

In subsequent years, as new features were added and algorithm improvements were made, it became apparent that a new protocol version was required.<ref name="MillsES">{{cite book|author=David L. Mills|title=Computer Network Time Synchronization: The Network Time Protocol on Earth and in Space, Second Edition|url=https://books.google.com/books?id=BxTOBQAAQBAJ&pg=PA377|date=15 November 2010|publisher=CRC Press|isbn=978-1-4398-1464-2|pages=377}}</ref> In 2010, {{IETF RFC|5905}} was published containing a proposed specification for NTPv4.<ref name="E4akm">{{citation| url=https://www.eecis.udel.edu/~mills/ntp.html| title=Network Time Synchronization Research Project| access-date=24 December 2014| section=Future Plans| archive-url=https://web.archive.org/web/20141223013515/http://www.eecis.udel.edu/~mills/ntp.html| archive-date=23 December 2014| url-status=live}}</ref> Following the retirement of Mills from the [[University of Delaware]], the reference implementation is currently maintained as an [[open source]] project led by Harlan Stenn.<ref name="jZjhj">{{cite web| url=http://www.informationweek.com/cloud/infrastructure-as-a-service/ntp-needs-money-is-a-foundation-the-answer/d/d-id/1319557| title=NTP Needs Money: Is A Foundation The Answer?| work=[[InformationWeek]]| date=March 23, 2015| access-date=April 4, 2015| archive-url=https://web.archive.org/web/20150410033108/http://www.informationweek.com/cloud/infrastructure-as-a-service/ntp-needs-money-is-a-foundation-the-answer/d/d-id/1319557| archive-date=April 10, 2015| url-status=live}}</ref><ref name="MShrI">{{cite web| url=http://www.informationweek.com/it-life/ntps-fate-hinges-on-father-time/d/d-id/1319432?cmp=em-prog-na-na-newsltr_20150313_control&imm_mid=0ce65e&page_number=2| title=NTP's Fate Hinges On 'Father Time'| work=[[InformationWeek]]| date=March 11, 2015| access-date=April 4, 2015| archive-url=https://web.archive.org/web/20150410021745/http://www.informationweek.com/it-life/ntps-fate-hinges-on-father-time/d/d-id/1319432?cmp=em-prog-na-na-newsltr_20150313_control&imm_mid=0ce65e&page_number=2| archive-date=April 10, 2015| url-status=live}}</ref> On the [[Internet Assigned Numbers Authority|IANA]] side, a ntp (network time ''protocols'') work group is in charge of reviewing proposed drafts.<ref name="ntpwg-doc">{{cite web |title=Network Time Protocols (ntp): Documents |url=https://datatracker.ietf.org/wg/ntp/documents/ |website=datatracker.ietf.org |access-date=27 December 2022 |language=en}}</ref>

The protocol has significantly progressed since NTPv4.<ref name="E4akm"/> {{as of|2022}}, three RFC documents describing updates to the protocol have been published,{{Ref RFC|7822}}{{Ref RFC|8573}}{{Ref RFC|9109}} not counting the numerous peripheral standards<ref name="ntpwg-doc"/> such as Network Time Security.{{Ref RFC|8915}} Mills had mentioned plans for a "NTPv5" on his page, but one was never published.<ref name="E4akm"/> An unrelated draft termed "NTPv5" by M. Lichvar of [[chrony]] was initiated in 2020 and includes security, accuracy, and scaling changes.<ref>{{cite journal |last1=Lichvar |first1=Miroslav |date=2 July 2025 |title=Network Time Protocol Version 5 |url=https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5/|journal= |language=en |website=www.ietf.org}}</ref>

=== SNTP ===
As NTP replaced the old [[Time Protocol]], some use cases nevertheless found the full protocol too complicated. In 1992, '''Simple Network Time Protocol''' ('''SNTP''') was defined to fill this niche. The SNTPv3 standard describes a way to use NTPv3 such that no storage of [[state (computer science)|state]] over an extended period is needed. The topology becomes essentially the same as with the Time Protocol, as only one server is used.{{Ref RFC|1361}} In 1996, SNTP was updated to SNTPv4,{{Ref RFC|2030}} with some features of the then-in-development NTPv4. SNTPv4 was merged into the main NTPv4 standard in 2010.{{Ref RFC|5905}} SNTP is fully interoperable with NTP since it does not define a new protocol.{{Ref RFC|5905|rsection=14|notes=no|status=no|quote=Primary servers and clients complying with a subset of NTP, called the Simple Network Time Protocol (SNTPv4) [...], do not need to implement the mitigation algorithms [...] The fully developed NTPv4 implementation is intended for [...] servers with multiple upstream servers and multiple downstream servers [...] Other than these considerations, NTP and SNTP servers and clients are completely interoperable and can be intermixed [...]}} However, the simple algorithms provide times of reduced accuracy and thus it is inadvisable to sync time from an SNTP source.{{Ref RFC|4330}}

== Clock strata ==
[[File:Usno-amc.jpg|thumb|The [[United States Naval Observatory|U.S. Naval Observatory]] Alternate Master Clock at [[Schriever Air Force Base|Schriever AFB (Colorado)]] is a stratum 0 source for NTP.]]
[[File:Network Time Protocol servers and clients.svg|thumb|Yellow arrows indicate a direct connection; red arrows indicate a network connection.]]

NTP uses a hierarchical, semi-layered system of time sources. Each level of this hierarchy is termed a ''stratum'' and is assigned a number starting with zero for the reference clock at the top. A server synchronized to a stratum ''n'' server runs at stratum ''n'' + 1. The number represents the distance from the reference clock and is used to prevent cyclical dependencies in the hierarchy. Stratum is not always an indication of quality or reliability; it is common to find stratum 3 time sources that are higher quality than some stratum 2 time sources.{{efn|Telecommunication systems use a different definition for [[Synchronization in telecommunications|clock strata]].}} Brief descriptions of strata 0, 1, 2 and 3 are provided below.

; Stratum 0
: These are high-precision timekeeping devices such as [[atomic clock]]s, [[GNSS]] (including [[GPS]]) or other [[radio clock]]s, or [[Precision Time Protocol|PTP]]-synchronized clocks.<ref>{{cite web |title=Combining PTP with NTP to Get the Best of Both Worlds |url=https://www.redhat.com/en/blog/combining-ptp-ntp-get-best-both-worlds |website=www.redhat.com |language=en |quote=Programs from the linuxptp package can be used in a combination with an NTP daemon. A PTP clock on a NIC is synchronized by ptp4l and is used as a reference clock by chronyd or ntpd for synchronization of the system clock.}}</ref> They generate a very accurate [[pulse per second]] signal that triggers an [[interrupt]] and timestamp on a connected computer. Stratum 0 devices are also known as ''reference clocks''. NTP servers cannot advertise themselves as stratum 0; a stratum field set to 0 in an NTP message indicates an unspecified stratum.{{Ref RFC|5905|rp=21}}
; Stratum 1
: These are computers whose [[system time]] is synchronized to within a few microseconds of their attached stratum 0 devices. Stratum 1 servers may peer with other stratum 1 servers for [[sanity check]] and backup.<ref name="cisco">{{cite web| url=http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a0080117070.shtml| title=Network Time Protocol: Best Practices White Paper| access-date=15 October 2013| archive-url=https://web.archive.org/web/20131001041853/http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a0080117070.shtml| archive-date=1 October 2013| url-status=live}}</ref> They are also referred to as primary time servers.<ref name="summary" /><ref name="faq" />
; Stratum 2
: These are computers that are synchronized over a network to stratum 1 servers. Often a stratum 2 computer queries several stratum 1 servers. Stratum 2 computers may also peer with other stratum 2 computers to provide more stable and robust time for all devices in the peer group.
; Stratum 3
: These are computers that are synchronized to stratum 2 servers. They employ the same algorithms for peering and data sampling as stratum 2, and can themselves act as servers for stratum 4 computers, and so on.

The upper limit for stratum is 15; stratum 16 is used to indicate that a device is unsynchronized. The NTP algorithms on each computer interact to construct a [[Bellman–Ford]] shortest-path [[spanning tree]], to minimize the accumulated round-trip delay to the stratum 1 servers for all the clients.<ref name="Mills2010" />{{rp|20}}

In addition to stratum, the protocol is able to identify the synchronization source for each server in terms of a reference identifier (refid).

{| class="wikitable sortable"
|+ Common time reference identifiers (refid) codes
|-
! Refid<ref name="MIvTF">{{cite web|url=https://nlug.ml1.co.uk/2012/01/ntpq-p-output/831|title='ntpq -p' output|website=NLUG.ML1.co.uk|access-date=2018-11-12|archive-url=https://web.archive.org/web/20181112141516/https://nlug.ml1.co.uk/2012/01/ntpq-p-output/831|archive-date=2018-11-12|url-status=live}}</ref>!! Clock Source
|-
| GOES || [[Geostationary Operational Environmental Satellite]] (described as “Geosynchronous Orbit Environment Satellite” in RFC 5905)
|-
| GPS || [[Global Positioning System]]
|-
| GAL || [[Galileo (satellite navigation)|Galileo]] Positioning System
|-
| PPS || Generic pulse-per-second
|-
| IRIG || Inter-Range Instrumentation Group
|-
| WWVB || LF Radio [[WWVB]] Fort Collins, Colorado 60&nbsp;kHz
|-
| DCF/PZF<ref>{{Cite web|title=IMS-PZF: PZF (DCF77) Correlation Receiver (Eurocard)|url=https://www.meinbergglobal.com/english/products/ims-pzf-receiver.htm|publisher=Meinberg Funkuhren GmbH & Co KG|access-date=2025-06-19}}</ref> || LF Radio [[DCF77]] Mainflingen, DE 77.5&nbsp;kHz
|-
| HBG || LF Radio [[HBG (time signal)|HBG]] Prangins, HB 75&nbsp;kHz (ceased operation)
|-
| MSF || LF Radio [[Time from NPL (MSF)|MSF]] Anthorn, UK 60&nbsp;kHz
|-
| JJY || LF Radio [[JJY]] Fukushima, JP 40&nbsp;kHz, Saga, JP 60&nbsp;kHz
|-
| LORC || MF Radio [[Loran-C]] station, 100&nbsp;kHz
|-
| TDF || [[TDF time signal|MF Radio Allouis, FR 162 kHz]]
|-
| CHU || HF Radio [[CHU (radio station)|CHU]] Ottawa, Ontario
|-
| WWV || HF Radio [[WWV (radio station)|WWV]] Fort Collins, Colorado
|-
| WWVH || HF Radio [[WWVH]] Kauai, Hawaii
|-
| NIST || [[NIST]] telephone modem
|-
| ACTS || NIST telephone modem
|-
| USNO || USNO telephone modem
|-
| PTB || German PTB time standard telephone modem
|-
| MRS || (Informal) Multi Reference Sources
|-
| GOOG || (Unofficial) Google Refid used by Google NTP servers as time4.google.com
|}

For servers on stratum 2 and below, the refid is an encoded form of the upstream time server's IP address. For IPv4, this is simply the 32-bit address; for IPv6, it would be the first 32 bits of the MD5 hash of the source address. Refids serve to detect and prevent timing loops to the first degree.{{Ref RFC|5905}}

The refid field is filled with status words in the case of kiss-o'-death (KoD) packets, which tell the client to stop sending requests so that the server can rest.{{Ref RFC|5905}} Some examples are INIT (initialization), STEP (step time change), and RATE (client requesting too fast).<ref>{{cite web |title=Event Messages and Status Words |url=https://docs.ntpsec.org/latest/decode.html#kiss |website=docs.ntpsec.org |quote=Refid codes are used in kiss-o'-death (KoD) packets, the reference identifier field in ntpq and ntpmon billboard displays and log messages.}}</ref> The program output may additionally use codes not transmitted in the packet to indicate error, such as XFAC to indicate a network disconnection.<ref name="MIvTF"/>

The IANA maintains a registry for refid source names and KoD codes. Informal assignments can still appear.<ref>{{cite web |title=Network Time Protocol (NTP) Parameters |url=https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml |website=www.iana.org}}</ref>

== Software implementations ==
{{Further|ntpd#Implementations}}
[[File:Ntpq on Windows 11 screenshot.webp|thumb|upright=1.2|The NTP management protocol utility <code>ntpq</code> under [[Windows 11]] being used to query the state of stratum 1 time servers and verify proper operation of the client]]

=== Reference implementation ===
The NTP [[reference implementation]], along with the protocol, has been continuously developed for over 20 years. Backwards compatibility has been maintained as new features have been added. It contains several sensitive algorithms, especially to discipline the clock, that can misbehave when synchronized to servers that use different algorithms. The software has been [[ported]] to almost every computing platform, including personal computers. It runs as a [[Daemon (computing)|daemon]] called [[ntpd]] under Unix or as a [[Windows service|service]] under Windows. Reference clocks are supported and their offsets are filtered and analysed in the same way as remote servers, although they are usually polled more frequently.<ref name="Mills2010" />{{rp|15–19}} This implementation was audited in 2017, finding 14 potential security issues.<ref name="jAgTl">{{cite web | url=https://wiki.mozilla.org/images/e/ea/Ntp-report.pdf | title=Pentest-Report NTP 01.2017 | publisher=Cure53 | date=2017 | access-date=2019-07-03 | archive-url=https://web.archive.org/web/20181201232241/https://wiki.mozilla.org/images/e/ea/Ntp-report.pdf | archive-date=2018-12-01 | url-status=live}}</ref>

=== Windows Time ===
All [[Microsoft Windows]] versions since [[Windows 2000]] include the Windows Time service (W32Time),<ref name="ciu7z">{{cite web |url=https://technet.microsoft.com/en-us/library/cc773061%28WS.10%29.aspx |title=Windows Time Service Technical Reference |publisher=technet.microsoft.com |date=2011-08-17 |access-date=2011-09-19 |archive-url=https://web.archive.org/web/20110906143547/http://technet.microsoft.com/en-us/library/cc773061(WS.10).aspx |archive-date=2011-09-06 |url-status=live}}</ref> which has the ability to synchronize the computer clock to an NTP server.

W32Time was originally implemented for the purpose of the [[Kerberos (protocol)|Kerberos]] version 5 authentication protocol, which required time to be within 5 minutes of the correct value to prevent [[replay attack]]s. The network time server in Windows 2000 Server (and Windows XP) does not implement NTP disciplined synchronization, only locally disciplined synchronization with NTP/SNTP correction.<ref name="gn3Ev">{{cite web |url=https://support.ntp.org/bin/view/Support/WindowsTimeService |title=Windows Time Service page at NTP.org |website=Support.NTP.org |date=2008-02-25 |access-date=2017-05-01 |archive-url=https://web.archive.org/web/20170514214217/http://support.ntp.org/bin/view/Support/WindowsTimeService |archive-date=2017-05-14 |url-status=live}}</ref>

Beginning with [[Windows Server 2003]] and [[Windows Vista]], the NTP provider for W32Time became compatible with a significant subset of NTPv3.<ref name="AD2ab">{{cite web |url=https://technet.microsoft.com/en-us/library/cc773013%28WS.10%29.aspx |title=How the Windows Time Service Works |publisher=technet.microsoft.com |date=2010-03-12 |access-date=2011-09-19 |archive-url=https://web.archive.org/web/20110924184432/http://technet.microsoft.com/en-us/library/cc773013(WS.10).aspx |archive-date=2011-09-24 |url-status=live}}</ref> Microsoft states that W32Time cannot reliably maintain time synchronization with one second accuracy.<ref name="kb939322">{{cite web | url = http://support.microsoft.com/kb/939322 | title = Support boundary to configure the Windows Time service for high accuracy environments | date = 2011-10-19 | publisher = [[Microsoft]] | access-date = 2008-12-10 | archive-url = https://web.archive.org/web/20090112213922/http://support.microsoft.com/kb/939322 | archive-date = 2009-01-12 | url-status = live}}</ref> If higher accuracy is desired, Microsoft recommends using a newer version of Windows or different NTP implementation.<ref name="ihlx1">{{cite web | url = https://docs.microsoft.com/en-us/archive/blogs/askds/high-accuracy-w32time-requirements | title = High Accuracy W32time Requirements | date = 2007-10-23 | author = Ned Pyle | publisher = [[Microsoft]] | access-date = 2012-08-26 | archive-url = https://web.archive.org/web/20121017165107/http://blogs.technet.com/b/askds/archive/2007/10/23/high-accuracy-w32time-requirements.aspx | archive-date = 2012-10-17 | url-status = live}}</ref>

Beginning with [[Windows 10]] version 1607 and [[Windows Server 2016]], W32Time can be configured to reach time accuracy of 1 s, 50 ms or 1&nbsp;ms under certain specified operating conditions.<ref name="FvW7f">{{cite web |url=https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-2016-accurate-time |website=technet.microsoft.com |title=Windows Server 2016 Accurate Time |access-date=2016-12-07 |archive-url=https://web.archive.org/web/20161202233231/https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-2016-accurate-time |archive-date=2016-12-02 |url-status=live}}</ref><ref name="kb939322" /><ref>{{Cite web|last=dahavey|title=Support boundary for high-accuracy time|url=https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/support-boundary|access-date=2021-07-24|website=docs.microsoft.com|language=en-us|archive-date=2 May 2021|archive-url=https://web.archive.org/web/20210502120540/https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/support-boundary|url-status=live}}</ref>

=== OpenNTPD ===
In 2004, Henning Brauer of [[OpenBSD]] presented [[OpenNTPD]], an NTPv3/SNTPv4<ref>{{cite web |title=ntpd(8) - OpenBSD manual pages |url=https://man.openbsd.org/ntpd |website=man.openbsd.org |quote=It implements the Simple Network Time Protocol version 4, as described in RFC 5905, and the Network Time Protocol version 3, as described in RFC 1305.}}</ref> implementation with a focus on security and encompassing a privilege separated design. Whilst it is aimed more closely at the simpler generic needs of OpenBSD users, it also includes some protocol security improvements while still being compatible with existing NTP servers. The simpler code base sacrifices accuracy, deemed unnecessary in this use case.<ref name="accuracy">{{cite web |url = http://www.openbsd.org/faq/faq6.html#OpenNTPDaccurate |title = FAQ 6.12.1: 'But OpenNTPD isn't as accurate as the ntp.org daemon!' |author = The OpenBSD Project |date = 21 August 2006 |website = The OpenBSD Project |access-date = 2020-05-14 |archive-url = https://web.archive.org/web/20160205120110/http://www.openbsd.org/faq/faq6.html#OpenNTPDaccurate |archive-date = 2016-02-05 |url-status = dead}}</ref> A portable version is available in Linux package repositories.

=== NTPsec ===
NTPsec is a [[Fork (software development)|fork]] of the reference implementation that has been systematically [[Hardening (computing)|security-hardened]]. The fork point was in June 2015 and was in response to a series of compromises in 2014.<ref>{{Cite web |last=Raymond |first=Eric S. |date=2017-03-30 |title=NTPsec: a Secure, Hardened NTP Implementation {{!}} Linux Journal |url=https://www.linuxjournal.com/content/ntpsec-secure-hardened-ntp-implementation |url-status=live |archive-url=https://archive.today/20240126231434/https://www.linuxjournal.com/content/ntpsec-secure-hardened-ntp-implementation |archive-date=2024-01-26 |access-date=2024-01-26 |website=[[Linux Journal]]}}</ref> The first production release shipped in October 2017.<ref name="TLIYY">{{cite web|url=https://ntpsec.org|title=The Secure Network Time Protocol (NTPsec) Distribution|access-date=2019-01-12|archive-url=https://web.archive.org/web/20190113232124/https://ntpsec.org/|archive-date=2019-01-13|url-status=live}}</ref> Between removal of unsafe features, removal of support for obsolete hardware, and removal of support for obsolete Unix variants, NTPsec has been able to pare away 75% of the original codebase, making the remainder easier to [[Software quality assurance|audit]].<ref name="Liska2016">{{cite book|first=Allan|last=Liska|title=NTP Security: A Quick-Start Guide|url=https://books.google.com/books?id=AB-1DQAAQBAJ&pg=PA80|date=December 10, 2016|publisher=Apress|isbn=978-1-4842-2412-0|pages=80–}}</ref> A 2017 audit of the code showed eight security issues, including two that were not present in the original reference implementation, but NTPsec did not suffer from eight other issues that remained in the reference implementation.<ref name="5CF55">{{cite web |url=https://wiki.mozilla.org/images/1/10/Ntpsec-report.pdf |title=Pentest-Report NTPsec 01.2017 |publisher=Cure53 |date=2017 |access-date=2019-07-03 |archive-url=https://web.archive.org/web/20190704001204/https://wiki.mozilla.org/images/1/10/Ntpsec-report.pdf |archive-date=2019-07-04 |url-status=live}}</ref>

=== chrony ===
{{main|chrony}}
[[File:Chrony 4.6 screenshot.webp|thumb|upright=1.2|{{Proper name|chronyc}}, showing Network Time Security (NTS) sources and activity information]]

[[chrony]] is an independent NTP implementation mainly sponsored by [[Red Hat]], who uses it as the default time program in their distributions.<ref name="Q91Af">{{cite web |url= http://rhelblog.redhat.com/2016/07/20/combining-ptp-with-ntp-to-get-the-best-of-both-worlds/ |title= Combining PTP with NTP to Get the Best of Both Worlds |access-date = 19 November 2017 |last= Lichvar |first= Miroslav |date= 20 July 2016 |website= Red Hat Enterprise Linux Blog |quote= Starting with Red Hat Enterprise Linux 7.0 (and now in Red Hat Enterprise Linux 6.8) a more versatile NTP implementation is also provided via the chrony package |publisher= [[Red Hat]] |archive-url= https://web.archive.org/web/20160730091110/http://rhelblog.redhat.com/2016/07/20/combining-ptp-with-ntp-to-get-the-best-of-both-worlds/ |archive-date= 30 July 2016}}</ref> Being written from scratch, {{Proper name|chrony}} has a simpler codebase allowing for better security<ref name="kYgFj">{{cite web |url= https://www.coreinfrastructure.org/news/blogs/2017/09/securing-network-time |title= Securing Network Time |access-date = 19 November 2017 |date= 27 September 2017 |website= Core Infrastructure Initiative, a Linux Foundation Collaborative Project |quote= In sum, the Chrony NTP software stands solid and can be seen as trustworthy |publisher= Core Infrastructure Initiative |archive-url= https://web.archive.org/web/20171028123642/https://www.coreinfrastructure.org/news/blogs/2017/09/securing-network-time |archive-date= 28 October 2017}}</ref> and lower resource consumption.<ref name="jR9Jg"/> It does not however compromise on accuracy, instead syncing faster and better than the reference ntpd in many circumstances. It is versatile enough for ordinary computers, which are unstable, go into sleep mode or have intermittent connection to the Internet. It is also designed for virtual machines, a more unstable environment.<ref name="Both2018">{{cite web |last1=Both |first1=David |title=Manage NTP with Chrony |url=https://opensource.com/article/18/12/manage-ntp-chrony |website=Opensource.com |access-date=29 June 2019 |language=en |archive-url=https://web.archive.org/web/20190629174030/https://opensource.com/article/18/12/manage-ntp-chrony |archive-date=29 June 2019 |url-status=live}}</ref>

{{Proper name|chrony}} has been evaluated as "trustworthy", with only a few incidents.<ref name="tN0aV">{{cite web |url= https://wiki.mozilla.org/images/e/e4/Chrony-report.pdf |title= Pentest-Report Chrony 08.2017 |access-date = 19 November 2017 |last= Heiderich |first= Mario |date= August 2017 |website= Cure53.de Team |language = en |quote= Withstanding eleven full days of on-remote testing in August of 2017 means that Chrony is robust, strong, and developed with security in mind. |publisher= wiki.mozilla.org, AKA MozillaWiki or WikiMO |archive-url= https://web.archive.org/web/20171005123643/https://wiki.mozilla.org/images/e/e4/Chrony-report.pdf |archive-date= 5 October 2017}}</ref> It is able to achieve improved precision on LAN connections, using hardware timestamping on the network adapter.<ref name="Ocilw">{{cite web |url= https://chrony.tuxfamily.org/doc/4.3/chrony.conf.html#hwtimestamp |title= chrony – chrony.conf(5) |access-date = 2 August 2020 |last= Lichvar |first= Miroslav |date= 18 September 2018 |website= Chrony project |language= en |quote= This directive enables hardware timestamping of NTP packets sent to and received from the specified network interface. }}</ref> Support for Network Time Security (NTS) was added on version 4.0.<ref>{{Cite web|title=chrony/chrony.git - Official Git repository for the Chrony project.|url=https://git.tuxfamily.org/chrony/chrony.git/tree/NEWS?id=4.0#n6|access-date=2021-07-31|website=git.tuxfamily.org}}</ref> {{Proper name|chrony}} is available under [[GNU General Public License version 2]], was created by [[Richard Curnow]] in 1997 and is currently maintained by [[Miroslav Lichvar]].<ref name="jR9Jg">{{cite web |url= https://chrony.tuxfamily.org/ |title= chrony introduction |access-date = 19 November 2017 |website= TuxFamily, a non-profit organization. |quote= The software is supported on Linux, FreeBSD, NetBSD, macOS, and Solaris. |publisher= chrony |archive-url= https://web.archive.org/web/20091209115945/https://chrony.tuxfamily.org/ |archive-date= 9 December 2009}}</ref>

=== ntpd-rs ===
[[File:Ntp-ctl screenshot.webp|thumb|upright=1.2|{{Proper name|ntp-ctl}} (part of ntpd-rs), showing synchronization information and NTS sources]]
ntpd-rs is a security-focused implementation of the NTP protocol, founded by the [[Internet Security Research Group]] as part of their Prossimo initiative for the creation of memory safe Internet infrastructure. ntpd-rs is implemented in [[Rust (programming language)|Rust programming language]] which offers [[memory safety]] guarantees in addition to the [[Real-time computing]] capabilities which are required for an NTP implementation. ntpd-rs is used in security-sensitive environments such as the [[Let's Encrypt]] non-profit Certificate Authority.<ref>{{cite web |last1=Aas |first1=Josh |title=More Memory Safety for Let's Encrypt: Deploying ntpd-rs |url=https://letsencrypt.org/2024/06/24/ntpd-rs-deployment/ |website=Let's Encrypt |publisher=Let's Encrypt |access-date=18 December 2024 |ref=LEntpd}}</ref> Support for NTS is available.<ref>{{Cite web |title=Network Time Security - ntpd-rs documentation |url=https://docs.ntpd-rs.pendulum-project.org/guide/nts/ |access-date=2025-01-13 |website=docs.ntpd-rs.pendulum-project.org}}</ref> ntpd-rs is part of the "Pendulum" project which also includes a [[Precision Time Protocol]] implementation "statime". Both projects are available under [[Apache License|Apache]] and [[MIT License|MIT]] software licenses.

=== Others ===
* {{vanchor|Ntimed}} was started by [[Poul-Henning Kamp]] of [[FreeBSD]] in 2014 and abandoned in 2015.<ref name="F7zIq">{{cite web|last1=Poul-Henning|first1=Kamp|title=20140926 – Playing with time again|url=http://phk.freebsd.dk/time/20140926|website=PHK's Bikeshed|access-date=4 June 2015|archive-url=https://web.archive.org/web/20191220015844/http://phk.freebsd.dk/time/20140926/|archive-date=20 December 2019|url-status=live}}</ref> The implementation was sponsored by the [[Linux Foundation]].<ref name="HA4P8">{{cite web|last1=Poul-Henning|first1=Kamp|title=Network time synchronization software, NTPD replacement.|url=https://github.com/bsdphk/Ntimed|website=ntimed git repository README file|publisher=Github|access-date=4 June 2015|archive-url=https://web.archive.org/web/20150802090927/https://github.com/bsdphk/Ntimed/|archive-date=2 August 2015|url-status=live}}</ref>
* {{vanchor|systemd-timesyncd}} is the SNTP client built into [[systemd]]. It is used by [[Debian]] since version "bookworm"<ref>{{cite web |title=Switching from OpenNTPd to Chrony - anarcat |url=https://anarc.at/blog/2022-01-23-chrony/ |website=anarc.at|quote=So in effect, systemd-timesyncd became the default NTP daemon in Debian in bookworm, which I find somewhat surprising.}}</ref> and the downstream Ubuntu.

== Leap seconds ==
On the day of a [[leap second]] event, ntpd receives notification from either a [[configuration file]], an attached reference clock, or a remote server. Although the NTP clock is actually halted during the event, because of the requirement that time must appear to be [[Monotonic function|strictly increasing]], any [[Process (computing)|processes]] that query the system time cause it to increase by a tiny amount, preserving the order of events. If a negative leap second should ever become necessary, it would be deleted with the sequence 23:59:58, 00:00:00, skipping 23:59:59.<ref name="7hQhm">{{cite web |url=http://www.eecis.udel.edu/~mills/leap.html |title=The NTP Timescale and Leap Seconds |author=David Mills |access-date=15 October 2013 |archive-url=https://web.archive.org/web/20130907021050/http://www.eecis.udel.edu/%7emills/leap.html |archive-date=7 September 2013 |url-status=live}}</ref>

An alternative implementation, called leap smearing, consists in introducing the leap second incrementally during a period of 24 hours, from noon to noon in UTC time. This implementation is used by Google (both internally and on their public NTP servers), Amazon AWS,<ref name="kYj2y">{{cite web |url=https://developers.google.com/time/smear |title=Google Developers Leap Smear |access-date=4 April 2019 |archive-url=https://web.archive.org/web/20190404122431/https://developers.google.com/time/smear |archive-date=4 April 2019 |url-status=live}}</ref> and Facebook.<ref>{{cite journal |last1=Obleukhov |first1=Oleg |title=Building a more accurate time service at Facebook scale |journal=Engineering at Meta |date=18 March 2020 |url=https://engineering.fb.com/2020/03/18/production-engineering/ntp-service/}}</ref> {{Proper name|chrony}} supports leap smear in {{mono|smoothtime}} and {{mono|leapsecmode}} configurations, but such use is not to be mixed with a public NTP pool as leap smear is non-standard and will throw off client calculation in a mix.<ref>{{cite web |title=chrony – Frequently Asked Questions |url=https://chrony.tuxfamily.org/faq.html#_should_be_a_leap_smear_enabled_on_ntp_server |website=chrony.tuxfamily.org}}</ref>

== Security concerns ==
{{See also|NTP server misuse and abuse}}

Because adjusting system time is generally a privileged operation, part or all of NTP code has to be run with some privileges in order to support its core functionality. Only a few other security problems have been identified in the reference implementation of the NTP codebase, but those that appeared in 2009{{which|date=July 2022}} were cause for significant concern.<ref name="8pJKT">{{cite web |url=http://support.ntp.org/security |title=Security Notice |website=Support.NTP.org |date=2009-12-10 |access-date=2011-01-12 }}{{Dead link|date=November 2023 |bot=InternetArchiveBot |fix-attempted=yes }}</ref><ref name="DoZBy">{{cite web |url=https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20090923-ntp |title=Cisco IOS Software Network Time Protocol Packet Vulnerability |date=23 September 2009 |publisher=[[Cisco Systems]] |access-date=11 June 2020 |archive-url=https://web.archive.org/web/20200611155551/https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20090923-ntp |archive-date=11 June 2020 |url-status=live}}</ref> The protocol has been undergoing revision and review throughout its history. The codebase for the reference implementation has undergone security audits from several sources for several years.<ref name="ZD0x6">{{cite web|url=http://support.ntp.org/Main/CodeAudit |title=Code Audit |website=Support.NTP.org |date=2009-06-13 |access-date=2011-01-12}}</ref>

A [[stack buffer overflow]] exploit was discovered and patched in 2014.<ref name="m0CJK">{{cite web |url=https://ics-cert.us-cert.gov/advisories/ICSA-14-353-01 |title=Network Time Protocol Vulnerabilities (Update C) &#124; ICS-CERT |publisher=Ics-cert.us-cert.gov |access-date=2015-04-15 |archive-url=https://web.archive.org/web/20141220002022/https://ics-cert.us-cert.gov/advisories/ICSA-14-353-01 |archive-date=2014-12-20 |url-status=live}}</ref> [[Apple Inc.|Apple]] was concerned enough about this vulnerability that it used its auto-update capability for the first time.<ref name="zg08P">{{cite web | url=https://arstechnica.com/apple/2014/12/apple-automatically-patches-macs-to-fix-severe-ntp-security-flaw/ | title=Apple automatically patches Macs to fix severe NTP security flaw | publisher=arstechnica | date=Dec 23, 2014 | access-date=Apr 29, 2015 | last=Cunningham | first=Andrew | archive-url=https://web.archive.org/web/20150415002211/http://arstechnica.com/apple/2014/12/apple-automatically-patches-macs-to-fix-severe-ntp-security-flaw/ | archive-date=April 15, 2015 | url-status=live}}</ref> On systems using the reference implementation, which is running with root user's credential, this could allow unlimited access. Some other implementations, such as [[OpenNTPD]], have smaller code base and adopted other mitigation measures like privilege separation, are not subject to this flaw.<ref name="PW78Z">{{cite web | url=http://www.i-programmer.info/news/149-security/8120-ntp-the-latest-open-source-security-problem.html | title=NTP The Latest Open Source Security Problem | publisher=I Programmer | date=23 December 2014 | last=Fairhead | first=Harry | access-date=24 December 2014 | archive-url=https://web.archive.org/web/20141224071634/http://www.i-programmer.info/news/149-security/8120-ntp-the-latest-open-source-security-problem.html | archive-date=24 December 2014 | url-status=dead}}</ref>

A 2017 security audit of three NTP implementations, conducted on behalf of the Linux Foundation's Core Infrastructure Initiative, suggested that both NTP<ref name="VBrX5">''[http://support.ntp.org/bin/view/Main/SecurityNotice NTP SecurityNotice Page] {{Webarchive|url=https://web.archive.org/web/20140219093152/http://support.ntp.org/bin/view/Main/SecurityNotice |date=2014-02-19}}''</ref><ref name="T0ZbX">''[https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Antp&cpe_product=cpe%3A%2F%3A%3Antp NVD NIST Product Search NTP]''</ref> and NTPsec<ref name="YK5og">''[https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Antpsec&cpe_product=cpe%3A%2F%3A%3Antpsec NVD NIST Product Search NTPsec] {{Webarchive|url=https://web.archive.org/web/20200626160445/https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Antpsec&cpe_product=cpe%3A%2F%3A%3Antpsec |date=2020-06-26}}''</ref> were more problematic than chrony<ref name="rPdf5">''[https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Atuxfamily&cpe_product=cpe%3A%2F%3A%3Achrony NVD NIST Product Search Chrony] {{Webarchive|url=https://web.archive.org/web/20200626200844/https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Atuxfamily&cpe_product=cpe%3A%2F%3A%3Achrony |date=2020-06-26}}''</ref> from a security standpoint.<ref name="nPXeu">{{cite web |url=https://www.linuxfoundation.org/blog/cii-audit-identifies-secure-ntp-implementation/ |archive-url=https://web.archive.org/web/20180203195701/https://www.linuxfoundation.org/blog/cii-audit-identifies-secure-ntp-implementation/ |archive-date=2018-02-03 | title=CII Audit Identifies Most Secure NTP Implementation |publisher=The Linux Foundation |date=September 28, 2017 |access-date=2019-07-03}}</ref>

NTP servers can be susceptible to [[man-in-the-middle attack]]s unless packets are cryptographically signed for authentication.<ref name="cGifv">{{cite IETF | rfc=5906 | title=Network Time Protocol Version 4: Autokey Specification | publisher=IETF | date=June 2010}}</ref> The computational overhead involved can make this impractical on busy servers, particularly during [[denial of service]] attacks.<ref name="7a6Kk">{{cite web | url=http://www.eecis.udel.edu/~mills/security.html | title=NTP Security Analysis | access-date=11 October 2013 | archive-url=https://web.archive.org/web/20130907040625/http://www.eecis.udel.edu/%7emills/security.html | archive-date=7 September 2013 | url-status=dead}}</ref> NTP message [[Spoofing attack|spoofing]] from a man-in-the-middle attack can be used to alter clocks on client computers and allow a number of attacks based on bypassing of cryptographic key expiration.<ref name="OcBCA">{{cite web | url=https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf | title=Bypassing HTTP Strict Transport Security | date=2014-10-16 | access-date=2014-10-16 | author=Jose Selvi | archive-url=https://web.archive.org/web/20141018053055/https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf | archive-date=2014-10-18 | url-status=dead}}</ref> Some of the services affected by fake NTP messages identified are [[Transport Layer Security|TLS]], [[DNSSEC]], various caching schemes (such as DNS cache), [[Border Gateway Protocol]] (BGP), Bitcoin {{Citation needed|reason=the whole point of PoW is to avoid timestamps, this does not makes sense|date=April 2022}}and a number of persistent login schemes.<ref name="CjQpl">{{Cite journal | url=http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf | title=Attacking the Network Time Protocol | author1=Aanchal Malhotra | author2=Isaac E. Cohen | author3=Erik Brakke | author4=Sharon Goldberg | name-list-style=amp | date=20 October 2015 | journal=NDSS | archive-url=https://web.archive.org/web/20151022140151/http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf | archive-date=22 October 2015 | url-status=dead | access-date=27 October 2015}}</ref><ref name="PglM9">{{Cite web | title = Attacking the Network Time Protocol | url = http://www.cs.bu.edu/~goldbe/NTPattack.html | website = www.cs.bu.edu | access-date = 2015-10-27 | archive-url = https://web.archive.org/web/20151024172618/http://www.cs.bu.edu/~goldbe/NTPattack.html | archive-date = 2015-10-24 | url-status = dead}}</ref>

NTP has been used in [[distributed denial of service attack]]s.<ref name="ElmaH">{{cite web |last=Goodin |first=Dan |url=https://arstechnica.com/security/2014/01/new-dos-attacks-taking-down-game-sites-deliver-crippling-100-gbps-floods/ |title=New DoS attacks taking down game sites deliver crippling 100Gbps floods |website=Ars Technica |date=2014-01-13 |access-date=2014-01-25 |archive-url=https://web.archive.org/web/20140124074451/http://arstechnica.com/security/2014/01/new-dos-attacks-taking-down-game-sites-deliver-crippling-100-gbps-floods/ |archive-date=2014-01-24 |url-status=live}}</ref><ref name="Eb0sO">{{cite web |last=Lee |first=Dave |url=https://www.bbc.co.uk/news/technology-26136774 |title=Huge Hack 'Ugly Sign of Future' for Internet Threats |publisher=BBC |date=2014-02-11 |access-date=2014-02-12 |archive-url=https://web.archive.org/web/20140211175533/http://www.bbc.co.uk/news/technology-26136774 |archive-date=2014-02-11 |url-status=live}}</ref> A small query is sent to an NTP server with the return [[IP address spoofing|IP address spoofed]] to be the target address. Similar to the [[DNS amplification attack]], the server responds with a much larger reply that allows an attacker to substantially increase the amount of data being sent to the target. To avoid participating in an attack, NTP server software can be upgraded or servers can be configured to ignore external queries.<ref name="wkYHy">{{cite web|url=http://support.ntp.org/bin/view/Main/SecurityNotice#April_2010_DRDoS_Amplification_A|title=DRDoS / Amplification Attack using ntpdc monlist command|website=support.NTP.org|date=2010-04-24|access-date=2014-04-13|archive-url=https://web.archive.org/web/20140330131447/http://support.ntp.org/bin/view/Main/SecurityNotice#April_2010_DRDoS_Amplification_A|archive-date=2014-03-30|url-status=live}}</ref>

=== Secure extensions ===

NTP itself includes support for authenticating servers to clients. NTPv3 supports a [[symmetric key]] mode, which is not useful against MITM. The [[public key]] system known as "autokey" in NTPv4 adapted from [[IPSec]] offers useful authentication,<ref name="cGifv"/> but is not practical for a busy server.<ref name="7a6Kk"/> Autokey was also later found to suffer from several design flaws,<ref>{{Cite conference|url=https://www.ietf.org/proceedings/83/slides/slides-83-tictoc-1.pdf|title=Analysis of NTP's Autokey Protocol|author1=Dieter Sibold|author2=Stephen Röttger|conference=IETF 83|date=2012}}</ref> with no correction published, save for a change in the [[message authentication code]].{{Ref RFC|8573}}  Autokey should no longer be used.{{ref RFC|8633|section=4.2}}

'''Network Time Security''' (NTS) is a secure version of NTPv4 with [[Transport Layer Security|TLS]] and [[Authenticated encryption|AEAD]].<ref>{{Cite web|title=nts.time.nl homepage|url=https://nts.time.nl/|access-date=2021-08-19|website=nts.time.nl}}</ref> The main improvement over previous attempts is that a separate "key establishment" server handles the heavy asymmetric cryptography, which needs to be done only once. If the server goes down, previous users would still be able to fetch time without fear of MITM.{{Ref RFC|8915}} NTS is supported by several NTP servers including [[Cloudflare]] and [[Netnod]].<ref>{{Cite web|last=Langer|first=Martin|date=2019-12-05|title=Setting up NTS-Secured NTP with NTPsec|url=https://weberblog.net/setting-up-nts-secured-ntp-with-ntpsec/|access-date=2021-08-19|website=Weberblog.net|language=en-US}}</ref><ref>{{Cite web|title=How to use NTS {{!}} Netnod|url=https://www.netnod.se/time-and-frequency/how-to-use-nts|access-date=2021-08-19|website=Netnod}}</ref> It can be enabled on {{Proper name|chrony}}, NTPsec, and ntpd-rs.<ref>{{cite web |date=13 August 2024 |title=Network Time Security · Cloudflare Time Services docs |url=https://developers.cloudflare.com/time-services/nts/ |access-date=12 January 2025 |website=developers.cloudflare.com |language=en}}</ref>

Microsoft also has an approach to authenticate NTPv3/SNTPv4 packets using a [[Windows domain]] identity, known as MS-SNTP.<ref>{{cite web | url=https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sntp/8106cb73-ab3a-4542-8bc8-784dd32031cc | title=&#91;MS-SNTP&#93;: Network Time Protocol (NTP) Authentication Extensions | date=24 June 2021 }}</ref> This system is implemented in the reference ntpd and chrony, using [[Samba (software)|samba]] for the domain connection.<ref name="comparison">{{Cite web|title=Comparison of NTP implementations|url=https://chrony.tuxfamily.org/comparison.html|publisher=chrony.tuxfamily.org|accessdate=2019-10-08}}</ref>

== NTP packet header format ==

{{APHD|start|title=NTP packet header format{{Ref RFC|5905|rsection=7.3}}}}

<!-- First 32 bits (four 8-bit fields): LI, VN, Mode, Stratum, Poll, Precision -->
{{APHD|0
 |field1=LI
 |bits1=2
 |field2=VN
 |bits2=3
 |field3=Mode
 |bits3=3
 |field4=Stratum
 |bits4=8
 |field5=Poll
 |bits5=8
 |field6=Precision
 |bits6=8
}}

<!-- Next three 32-bit fields: Root Delay, Root Dispersion, Reference ID -->
{{APHD|4
 |field1=Root Delay
 |bits1=32
}}
{{APHD|8
 |field1=Root Dispersion
 |bits1=32
}}
{{APHD|12
 |field1=Reference ID
 |bits1=32
}}

<!-- Each of the next four 64-bit fields: Reference/Origin/Receive/Transmit Timestamps -->
{{APHD|16
 |field1=Reference Timestamp (64-bits)
 |bits1=64
}}
{{APHD|24
 |field1=Origin Timestamp (64-bits)
 |bits1=64
}}
{{APHD|32
 |field1=Receive Timestamp (64-bits)
 |bits1=64
}}
{{APHD|40
 |field1=Transmit Timestamp (64-bits)
 |bits1=64
}}

<!-- Extension fields (variable length); each extension field is typically a multiple of 32 bits -->
{{APHD|48
 |field1=Optional: Extension Field(s) (n * 32 bits)
 |bits1=32
|background1=linen
}}

<!-- (If a MAC is present) Key Identifier (32 bits) + 128-bit digest -->
{{APHD|52
 |field1=Optional: Key Identifier (If a MAC is present)
 |bits1=32
|background1=linen
}}
{{APHD|56
 |field1=Optional: Message Digest (dgst) (If a MAC is present)
 |bits1=128
|background1=linen
}}

{{APHD|end}}

;{{APHD|def|name=LI (Leap Indicator)|length=2 bits
|text=Warning of leap second insertion or deletion:
* 0 = no warning
* 1 = last minute has 61 seconds
* 2 = last minute has 59 seconds
* 3 = unknown (clock unsynchronized)}}

;{{APHD|def|name=VN (Version Number)|length=3 bits
|text=NTP version number, typically 4.}}

;{{APHD|def|name=Mode|length=3 bits
|text=Association mode:
* 0 = reserved
* 1 = symmetric active
* 2 = symmetric passive
* 3 = client
* 4 = server
* 5 = broadcast
* 6 = control
* 7 = private}}

;{{APHD|def|name=Stratum|length=8 bits
|text=Indicates the distance from the reference clock. 
* 0 = invalid
* 1 = primary server
* 2–15 = secondary
* 16 = unsynchronized}}

;{{APHD|def|name=Poll|length=8 bits
|text=Maximum interval between successive messages, in log₂(seconds). Typical range is 6 to 10.}}
;{{APHD|def|name=Precision|length=8 bits
|text=Signed log₂(seconds) of system clock precision (e.g., –18 ≈ 1 microsecond).}}
;{{APHD|def|name=Root Delay|length=32 bits
|text=Total round-trip delay to the reference clock, in NTP short format.}}
;{{APHD|def|name=Root Dispersion|length=32 bits
|text=Total dispersion to the reference clock, in NTP short format.}}
;{{APHD|def|name=Reference ID|length=32 bits
|text=Identifies the specific server or reference clock; interpretation depends on Stratum.}}
;{{APHD|def|name=Reference Timestamp|length=64 bits
|text=Time when the system clock was last set or corrected, in NTP timestamp format.}}
;{{APHD|def|name=Origin Timestamp (org)|length=64 bits
|text=Time at the client when the request departed, in NTP timestamp format.}}
;{{APHD|def|name=Receive Timestamp (rec)|length=64 bits
|text=The local time, in timestamp format, when the latest NTP message arrived.}}
;{{APHD|def|name=Transmit Timestamp (xmt)|length=64 bits
|text=Time at the server when the response left, in NTP timestamp format.}}
;{{APHD|def|name=Extension Field|length=variable
|text=Optional field(s) for NTP extensions (see {{Ref RFC|5905}}, Section 7.5).}}
;{{APHD|def|name=Key Identifier|length=32 bits
|text=Unsigned integer designating an MD5 key shared by the client and server.}}
;{{APHD|def|name=Message Digest (MD5)|length=128 bits
|text=MD5 hash covering the packet header and extension fields, used for authentication.}}

=== Timestamps ===
The 64-bit [[fixed-point arithmetic|binary fixed-point]] timestamps used by NTP consist of a 32-bit part for seconds and a 32-bit part for fractional second, giving a time scale that [[Integer overflow|rolls over]] every 2<sup>32</sup> seconds (136 years) and a theoretical resolution of 2<sup>−32</sup> seconds (233 picoseconds). NTP uses an [[epoch]] of January 1, 1900. Therefore, the first rollover occurs on February 7, 2036.<ref name="mvUS1">{{cite web |url=https://www.eecis.udel.edu/~mills/y2k.html |author=David L. Mills |title=The NTP Era and Era Numbering |date=12 May 2012 |access-date=24 September 2016 |archive-url=https://web.archive.org/web/20161026011515/https://www.eecis.udel.edu/~mills/y2k.html |archive-date=26 October 2016 |url-status=live}}</ref><ref name="StevensFenner2004">{{cite book |author1=W. Richard Stevens |author2=Bill Fenner |author3=Andrew M. Rudoff |title=UNIX Network Programming |url=https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA582 |year=2004 |publisher=Addison-Wesley Professional |isbn=978-0-13-141155-5 |pages=582– |access-date=2016-10-16 |archive-url=https://web.archive.org/web/20190330170620/https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA582 |archive-date=2019-03-30 |url-status=live}}</ref>

NTPv4 introduces a 128-bit date format: 64 bits for the second and 64 bits for the fractional-second. However, the 128-bit format is never transmitted as the standard states that eras "cannot be produced by NTP directly, nor is there need to do so."<ref>{{Cite report |url=https://datatracker.ietf.org/doc/rfc5905/ |title=Network Time Protocol Version 4: Protocol and Algorithms Specification |last=Martin |first=Jim |last2=Burbank |first2=Jack |last3=Kasch |first3=William |last4=Mills |first4=Professor David L. |date=June 2010 |publisher=Internet Engineering Task Force |issue=RFC 5905 |page=12}}</ref> The most-significant 32 bits of this format is the ''Era Number'' which would resolve rollover ambiguity in most cases.<ref name="bzRE9">{{cite web |title=A look at the Year 2036/2038 problems and time proofness in various systems |date=14 March 2017 |url=http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/ |access-date=2018-07-20 |archive-url=https://web.archive.org/web/20180721014309/http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/ |archive-date=2018-07-21 |url-status=live}}</ref> According to Mills, "The 64-bit value for the fraction is enough to resolve the amount of time it takes a photon to pass an electron at the speed of light. The 64-bit second value is enough to provide unambiguous time representation until the universe goes dim."<ref name="FIILt">[[University of Delaware]] Digital Systems Seminar presentation by David Mills, 2006-04-26</ref>{{efn|2<sup>−64</sup> seconds is about [[1 E-21 s|54 zeptoseconds]] (light would travel 16.26 picometers, or approximately 0.31 × [[Bohr radius]]), and 2<sup>64</sup> seconds is about [[1 E19 s and more|585 billion years]].}}

== See also ==

* {{Annotated link|Allan variance}}
* {{Annotated link|Clock network}}
* {{Annotated link|International Atomic Time}}
* {{Annotated link|IRIG timecode}}
* {{Annotated link|NITZ}}
* {{Annotated link|NTP pool}}
* {{Annotated link|Ntpdate}}
* {{Annotated link|Precision Time Protocol}}

== Notes ==
{{Notelist}}

== References ==
{{reflist}}

== Further reading ==
* {{cite IETF |rfc=5907 |title=Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)}}
* {{cite IETF |rfc=5908 |title=Network Time Protocol (NTP) Server Option for DHCPv6}}
* [https://datatracker.ietf.org/doc/html/draft-ietf-ntp-data-minimization draft-ietf-ntp-data-minimization NTP Client Data Minimization I-D]

== External links ==
* {{Official website}}
* [http://support.ntp.org/bin/view/Servers/StratumOneTimeServers Official Stratum One Time Servers list]
* [https://datatracker.ietf.org/wg/ntp/charter/ IETF NTP working group]
* [https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/accurate-time Microsoft Windows accurate time guide] and [https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/configuring-systems-for-high-accuracy?tabs=MinPollInterval more]
* [https://www.ijs.si/time/ Time and NTP paper]
* [https://web.archive.org/web/20190504164134/http://ntpsurvey.arauc.br/ NTP Survey 2005]
* [https://www.ietf.org/timezones/data/leap-seconds.list Current NIST leap seconds file compatible with ntpd]
* {{citation |author=David L. Mills |url=https://www.eecis.udel.edu/~mills/database/papers/history.pdf |title=A Brief History of NTP Time: Confessions of an Internet Timekeeper |access-date=2021-02-07}}

[[Category:Application layer protocols]]
[[Category:Internet Standards]]
[[Category:Network time-related software]]