Which ntp version

SNTP is considered a still supported legacy mode of Windows time service. As I wrote above, it is needed for communications with legacy general purpose computing devices as well as for communications with limited embedded devices. For 12 to 15 years now, Windows time service switched its defaults. Windows time service can be configured to something close to a subset of ntp v3. This is the default of Windows time service when several external non-Windows time sources are specified. I'm more active in technical software projects.

In your case, is it such a self-assessment or an external audit? So for the purpose of your audit, I would declare it Windows time service instead of ntp. The Wikipedia article declares it fully compliant with ntp while Microsoft denies having made such claims pronounced by Wikipedia. There is some compatibility with ntp v3. And there are different modes available within Windows time service.

So as you have now a deeper understanding of Windows time service and its relations to ntp and SNTP as well as of its different modes of operations as well as alternatives, you may do an overview if additional comments make sense in your audit or are already covered in the areas of time accuracy and time service vulnerability.

But I assume that beside doing such an audit, you should take additional notes how long it will still be possible to operate Windows server R2 in a compliant manner. I expect there are known dates where you'll need to either redesign such deployment or migrate to a more recent platform.

If you want to stick with Windows, even a more recent version of an embedded edition of Windows could be an option. The advantage of embedded editions is that you may gain better controls over lattencies and that you may much better downstrip the operating system for deployment as needed. Once extended support runs out - it will have to be upgraded. Get answers from your peers along with millions of IT pros who visit Spiceworks.

Best Answer. LarryCK wrote: however, one of the links that supposedly gives the answer is dead and the other one does not seem to mention NTP protocol version anywhere. If you need full ntp compliance , you may choose other implementations, including the reference implementation.

As far as I remember, the reference implementation for ntp v4 is available for Windows , including Windows Server R2 and Windows Server There are instructions how to integrate that reference implementation into Windows.

The above mentioned Wikipedia article also mentions that this reference implementation has been audited in and several security issues found.

I don't know to which extent this fixes have been addressed since. Its latest update is of June And if you need high network time accuracy, there exist other protocol standards which are available also for Windows. By signing in, you agree to our Terms of Use and Privacy Policy.

Already have an account? Sign in. By signing up, you agree to our Terms of Use and Privacy Policy. Enter the email address associated with your account. We'll send a magic link to your inbox. Email Address. Definitions A number of technical terms are defined in this section. A timescale is a frame of reference where time is expressed as the value of a monotonically increasing binary counter with an indefinite number of bits.

It counts in seconds and fractions of a second, when a decimal point is employed. The Coordinated Universal Time UTC timescale represents mean solar time as disseminated by national standards laboratories. The system time is represented by the system clock maintained by the hardware and operating system. The goal of the NTP algorithms is to minimize both the time difference and frequency difference between UTC and the system clock. When these differences have been reduced below nominal tolerances, the system clock is said to be synchronized to UTC.

Dates are ephemeral values designated with uppercase T. Running time is another timescale that is coincident to the synchronization function of the NTP program. Which meaning is intended should be clear from the context. Let T t be the time offset, R t the frequency offset, and D t the aging rate first derivative of R t with respect to t. While the D t term is important when characterizing precision oscillators, it is ordinarily neglected for computer oscillators.

It is important in computer timekeeping applications to assess the performance of the timekeeping function. The NTP performance model includes four statistics that are updated each time a client makes a measurement with a server.

The offset theta represents the maximum-likelihood time offset of the server clock relative to the system clock. The delay delta represents the round-trip delay between the client and server. The dispersion epsilon represents the maximum error inherent in the measurement. It increases at a rate equal to the maximum disciplined system clock frequency tolerance PHI , typically 15 ppm.

The jitter psi is defined as the root-mean-square RMS average of the most recent offset differences, and it represents the nominal error in estimating the offset. While the theta, delta, epsilon, and psi statistics represent measurements of the system clock relative to each server clock separately, the NTP protocol includes mechanisms to combine the statistics of several servers to more accurately discipline and calibrate the system clock.

The system jitter PSI represents the nominal error in estimating the system offset. The detailed Mills, et al. They are available to the dependent applications in order to assess the performance of the synchronization function. Implementation Model Figure 2 shows the architecture of a typical, multi-threaded implementation. It includes two processes dedicated to each server, a peer process to receive messages from the server or reference clock, and a poll process to transmit messages to the server or reference clock.

Cluster Algorithm. Figure 2: Implementation Model Mills, et al. Standards Track [Page 10] RFC NTPv4 Specification June These processes operate on a common data structure, called an association, which contains the statistics described above along with various other data described in Section 9. A client sends packets to one or more servers and then processes returned packets when they are received.

As each NTP message is received, the offset theta between the peer clock and the system clock is computed along with the associated statistics delta, epsilon, and psi. The system process includes the selection, cluster, and combine algorithms that mitigate among the various servers and reference clocks to determine the most accurate and reliable candidates to synchronize the system clock. The selection algorithm uses Byzantine fault detection principles to discard the presumably incorrect candidates called "falsetickers" from the incident population, leaving only good candidates called "truechimers".

A truechimer is a clock that maintains timekeeping accuracy to a previously published and trusted standard, while a falseticker is a clock that shows misleading or inconsistent time. The cluster algorithm uses statistical principles to find the most accurate set of truechimers. The combine algorithm computes the final clock offset by statistically averaging the surviving truechimers. The clock discipline process is a system process that controls the time and frequency of the system clock, here represented as a variable frequency oscillator VFO.

Timestamps struck from the VFO close the feedback loop that maintains the system clock time. Associated with the clock discipline process is the clock-adjust process, which runs once each second to inject a computed time offset and maintain constant frequency. The RMS average of past time offset differences represents the nominal error or system clock jitter.

The RMS average of past frequency offset differences represents the oscillator frequency stability or frequency wander. These terms are given precise interpretation in Section In NTPv4, tau ranges from 4 16 s to 17 36 h. It is important that the dynamic behavior of the clock discipline algorithm be carefully controlled in order to maintain stability in the NTP subnet at large. This requires that Mills, et al. The NTP protocol includes provisions to properly negotiate this value.

The implementation model includes some means to set and adjust the system clock. The operating system is assumed to provide two functions: one to set the time directly, for example, the Unix settimeofday function, and another to adjust the time in small increments advancing or retarding the time by a designated amount, for example, the Unix adjtime function.

In this and following references, parentheses following a name indicate reference to a function rather than a simple variable. In the intended design the clock discipline process uses the adjtime function if the adjustment is less than a designated threshold, and the settimeofday function if above the threshold.

The manner in which this is done and the value of the threshold as described in Section Data Types All NTP time values are represented in twos-complement format, with bits numbered in big-endian as described in Appendix A of [RFC] fashion from zero starting at the left, or high-order, position.

There are three NTP time formats, a bit date format, a bit timestamp format, and a bit short format, as shown in Figure 3. The bit date format is used where sufficient storage and word size are available. It includes a bit signed seconds field spanning billion years and a bit fraction field resolving. For convenience in mapping between formats, the seconds field is divided into a bit Era Number field and a bit Era Offset field.

Eras cannot be produced by NTP directly, nor is there need to do so. When necessary, they can be derived from external means, such as the filesystem or dedicated hardware. It includes a bit unsigned seconds field spanning years and a bit fraction field resolving picoseconds. The bit short format is used in delay and dispersion header fields where the full resolution and range of the other formats are not justified. It includes a bit unsigned seconds field and a bit fraction field.

In the date and timestamp formats, the prime epoch, or base date of era 0, is 0 h 1 January UTC, when all bits are zero. It should be noted that strictly speaking, UTC did not exist prior to 1 January , but it is convenient to assume it has existed for all eternity, even if all knowledge of historic leap seconds has been lost.

Dates are relative to the prime epoch; values greater than zero represent Mills, et al. Note that the Era Offset field of the date format and the Seconds field of the timestamp format have the same interpretation. Timestamps are unsigned values, and operations on them produce a result in the same or adjacent eras. Era 0 includes dates from the prime epoch to some time in , when the timestamp field wraps around and the base date for era 1 is established.

In either format, a value of zero is a special case representing unknown or unsynchronized time. In order to minimize bias and help make timestamps unpredictable to an intruder, the non-significant bits should be set to an unbiased random bit string. The clock precision is defined as the running time to read the system clock, in seconds.

Note that the precision defined in this way can be larger or smaller than the resolution. The term rho, representing the precision used in the protocol, is the larger of the two. Standards Track [Page 14] RFC NTPv4 Specification June The only arithmetic operation permitted on dates and timestamps is twos-complement subtraction, yielding a bit or bit signed result. It is critical that the first-order differences between two dates preserve the full bit precision and the first-order differences between two timestamps preserve the full bit precision.

However, the differences are ordinarily small compared to the seconds span, so they can be converted to floating double format for further processing and without compromising the precision. It is important to note that twos-complement arithmetic does not distinguish between signed and unsigned values although comparisons can take sign into account ; only the conditional branch instructions do. Thus, although the distinction is made between signed dates and unsigned timestamps, they are processed the same way.

A perceived hazard with bit timestamp calculations spanning an era, such as is possible in , might result in over-run. In point of fact, if the client is set within 68 years of the server before the protocol is started, correct values are obtained even if the client and server are in adjacent eras.

Some time values are represented in exponent format, including the precision, time constant, and poll interval. These are in 8-bit signed integer format in log2 log base 2 seconds. The only arithmetic operations permitted on them are increment and decrement. For the purpose of this document and to simplify the presentation, a reference to one of these variables by name means the exponentiated value, e.

To convert system time in any format to NTP date and timestamp formats requires that the number of seconds s from the prime epoch to the system time be determined.

Converting between NTP and system time can be a little messy, and is beyond the scope of this document. Note that the number of days in era 0 is one more than the number of days in most other eras, and this won't happen again until the year in era 3.

This simplifies bounds checks, since only the upper limit needs to be defined. Without explicit reference, the default type is bit floating double. Exceptions will be noted as necessary.

State variables are separated into classes according to their function in packet headers, peer and poll processes, the system process, and the clock discipline process. Packet variables represent the NTP header values in transmitted and received packets. Peer and poll variables represent the contents of the association for each server separately. System variables represent the state of the server as seen by its dependent clients. Clock discipline variables represent the internal workings of the clock discipline algorithm.

An example is described in Appendix A. Structure Conventions In order to distinguish between different variables of the same name but used in different processes, the naming convention summarized in Figure 5 is adopted.

A receive packet variable v is a member of the packet structure r with fully qualified name r. In a similar manner, x. There is a set of peer variables for each association; there is only one set of system and clock variables. Global Parameters In addition to the variable classes, a number of global parameters are defined in this document, including those shown with values in Figure 6.

Appendix A. Others, like the frequency tolerance also called PHI , involve an assumption about the worst-case behavior of a system clock once synchronized and then allowed to drift when its sources have become unreachable. The minimum and maximum parameters define the limits of state variables as described in later sections of this document. While shown with fixed values in this document, some implementations may make them variables adjustable by configuration commands.

Packet Header Variables The most important state variables from an external point of view are the packet header variables described in Figure 7 and below.

The NTP packet header consists of an integral number of bit 4 octet words in network byte order. The packet format consists of three components: the header itself, one or more optional extension fields, and an optional message authentication code MAC. The header component is identical to the NTPv3 header and previous versions. The optional extension fields are used by the Autokey public key cryptographic algorithms described in [ RFC ]. Some fields use multiple words and others are packed in smaller fields within a word.

The NTP packet header shown in Figure 8 has 12 words followed by optional extension fields and finally an optional message authentication code MAC consisting of the Key Identifier field and Message Digest field. Extension Field 1 variable. Extension Field 2 variable. The extension field format is presented in order for the packet to be parsed without the knowledge of the extension field functions.

The MAC is used by both Autokey and the symmetric key authentication scheme. A list of the packet header variables is shown in Figure 7 and described in detail below.

Except for a minor variation when using the IPv6 address family, these fields are backwards compatible with NTPv3. The packet header fields apply to both transmitted packets x prefix and received packets r prefix. In Figure 8, the size of some multiple-word fields is shown in bits if not the default 32 bits. The basic header extends from the beginning of the packet to the end of the Transmit Timestamp field.

The fields and associated packet variables in parentheses are interpreted as follows: LI Leap Indicator leap : 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9.

Mode mode : 3-bit integer representing the mode, with values defined in Figure This allows reference clocks, which normally appear at stratum 0, to be conveniently mitigated using the same clock selection algorithms used for external sources see Appendix A. Poll: 8-bit signed integer representing the maximum interval between successive messages, in log2 seconds. Suggested default limits for minimum and maximum poll intervals are 6 and 10, respectively. Precision: 8-bit signed integer representing the precision of the system clock, in log2 seconds.

For instance, a value of corresponds to a precision of about one microsecond. The precision can be determined when the service first starts up as the minimum time of several iterations to read the system clock. Reference ID refid : bit code identifying the particular server or reference clock.

The interpretation depends on the value in the stratum field. For packet stratum 0 unspecified or invalid , this is a four-character ASCII [ RFC ] string, called the "kiss code", used for debugging and monitoring purposes. For stratum 1 reference clock , this is a four-octet, left-justified, zero-padded ASCII string assigned to the reference clock.

If using the IPv4 address family, the identifier is the four- octet IPv4 address. If using the IPv6 address family, it is the Mills, et al.

Note that, when using the IPv6 address family on an NTPv4 server with a NTPv3 client, the Reference Identifier field appears to be a random value and a timing loop might not be detected. Origin Timestamp org : Time at the client when the request departed for the server, in NTP timestamp format.

Receive Timestamp rec : Time at the server when the request arrived from the client, in NTP timestamp format. Transmit Timestamp xmt : Time at the server when the response left for the client, in NTP timestamp format. Destination Timestamp dst : Time at the client when the reply arrived from the server, in NTP timestamp format.

Note: The Destination Timestamp field is not included as a header field; it is determined upon arrival of the packet and made available in the packet buffer data structure. If the NTP has access to the physical layer, then the timestamps are associated with the beginning of the symbol after the start of frame. Otherwise, implementations should attempt to associate the timestamp to the earliest accessible point in the frame. Extension Field n: See Section 7. Key Identifier keyid : bit unsigned integer used by the client and server to designate a secret bit MD5 key.

The Kiss-o'-Death Packet If the Stratum field is 0, which implies unspecified or invalid, the Reference Identifier field can be used to convey messages useful for status reporting and access control. The KoD packets got their name because an early use was to tell clients to stop sending packets that violate server access controls. The strings are designed for character displays and log files.

A list of the currently defined kiss codes is given in Figure Recipients of kiss codes MUST inspect them and, in the following cases, take these actions: a. Other than the above conditions, KoD packets have no protocol significance and are discarded after inspection. AUTH Server authentication failed. AUTO Autokey sequence failed.

BCST The association belongs to a broadcast server. CRYP Cryptographic authentication or identification failed. DENY Access denied by remote server. DROP Lost peer in symmetric mode. RSTR Access denied due to local policy. INIT The association has not yet synchronized for the first time. MCST The association belongs to a dynamically discovered server.

NKEY No key found. Either the key was never installed or is not trusted. RATE Rate exceeded. The server has temporarily denied access because the client exceeded the rate threshold. RMOT Alteration of association from a remote host running ntpdc.

STEP A step change in system time has occurred, but the association has not yet resynchronized. Learn More. Resources for IT Professionals. Sign in. United States English.

Ask a question. Quick access. Search related threads. Remove From My Forums. Asked by:. Archived Forums. Windows Server General Forum.