draft-ietf-ntp-ntpv4-proto-01.txt   draft-ietf-ntp-ntpv4-proto-02.txt 
NTP WG J. Burbank, Ed. NTP WG J. Burbank, Ed.
Internet-Draft JHU APL Internet-Draft JHU/APL
Expires: April 26, 2006 J. Martin, Ed. Obsoletes: RFC 4330 (if approved) J. Martin, Ed.
Netzwert AG Expires: September 2, 2006 Netzwert AG
D. Mills D. Mills
U. Del. U. Del.
October 23, 2005 March 2006
The Network Time Protocol Version 4 Protocol Specification The Network Time Protocol Version 4 Protocol Specification
draft-ietf-ntp-ntpv4-proto-01 draft-ietf-ntp-ntpv4-proto-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2006. This Internet-Draft will expire on September 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The Network Time Protocol (NTP) is widely used to synchronize The Network Time Protocol (NTP) is widely used to synchronize
computer clocks in the Internet. This memorandum describes Version 4 computer clocks in the Internet. This memorandum describes Version 4
of the NTP (NTPv4), introducing several changes from Version 3 of NTP of the NTP (NTPv4), introducing several changes from Version 3 of NTP
(NTPv3) described in RFC 1305, including the introduction of a (NTPv3) described in RFC 1305, including the introduction of a
modified protocol header to accomodate Internet Protocol Version 6. modified protocol header to accomodate Internet Protocol Version 6.
NTPv4 also includes optional extensions to the NTPv3 NTPv4 also includes optional extensions to the NTPv3
protocol,including a dynamic server discovery mechanism and an protocol,including a dynamic server discovery mechanism.
authentication scheme designed specifically for multicast and
dynamically discovered servers.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NTP Timestamp . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
3. NTP Message Formats . . . . . . . . . . . . . . . . . . . . 7 2. NTP Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Leap Indicator (LI) . . . . . . . . . . . . . . . . . . . 8 3. NTP Message Formats . . . . . . . . . . . . . . . . . . . . . 6
3.2 Version (VN) . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Leap Indicator (LI) . . . . . . . . . . . . . . . . . . . 7
3.3 Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Version (VN) . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Stratum (Strat) . . . . . . . . . . . . . . . . . . . . . 10 3.3. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5 Poll Interval (Poll) . . . . . . . . . . . . . . . . . . . 10 3.4. Stratum (Strat) . . . . . . . . . . . . . . . . . . . . . 9
3.6 Precision (Prec) . . . . . . . . . . . . . . . . . . . . . 10 3.5. Poll Interval (Poll) . . . . . . . . . . . . . . . . . . . 9
3.7 Root Delay . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Precision (Prec) . . . . . . . . . . . . . . . . . . . . . 9
3.8 Root Dispersion . . . . . . . . . . . . . . . . . . . . . 10 3.7. Root Delay . . . . . . . . . . . . . . . . . . . . . . . . 9
3.9 Reference Identifier . . . . . . . . . . . . . . . . . . . 11 3.8. Root Dispersion . . . . . . . . . . . . . . . . . . . . . 10
3.10 Reference Timestamp . . . . . . . . . . . . . . . . . . 12 3.9. Reference Identifier . . . . . . . . . . . . . . . . . . . 10
3.11 Originate Timestamp . . . . . . . . . . . . . . . . . . 12 3.10. Reference Timestamp . . . . . . . . . . . . . . . . . . . 11
3.12 Receive Timestamp . . . . . . . . . . . . . . . . . . . 12 3.11. Originate Timestamp . . . . . . . . . . . . . . . . . . . 11
3.13 Transmit Timestamp . . . . . . . . . . . . . . . . . . . 12 3.12. Receive Timestamp . . . . . . . . . . . . . . . . . . . . 11
3.14 NTPv4 Extension Fields . . . . . . . . . . . . . . . . . 12 3.13. Transmit Timestamp . . . . . . . . . . . . . . . . . . . . 11
3.15 Authentication (optional) . . . . . . . . . . . . . . . 13 3.14. NTPv4 Extension Fields . . . . . . . . . . . . . . . . . . 12
4. NTP Protocol Operation . . . . . . . . . . . . . . . . . . . 14 3.15. Authentication (optional) . . . . . . . . . . . . . . . . 13
5. SNTP Protocol Operation . . . . . . . . . . . . . . . . . . 14 4. NTP Protocol Operation . . . . . . . . . . . . . . . . . . . . 14
6. NTP Server Operations . . . . . . . . . . . . . . . . . . . 15 5. SNTP Protocol Operation . . . . . . . . . . . . . . . . . . . 17
7. NTP Client Operations . . . . . . . . . . . . . . . . . . . 17 6. NTP Server Operations . . . . . . . . . . . . . . . . . . . . 18
8. NTP Symmetric Peer Operations . . . . . . . . . . . . . . . 20 7. NTP Client Operations . . . . . . . . . . . . . . . . . . . . 20
9. NTPv4 Security . . . . . . . . . . . . . . . . . . . . . . . 20 8. NTP Symmetric Peer Operations . . . . . . . . . . . . . . . . 22
9.1 Session Keys and Cookies . . . . . . . . . . . . . . . . . 20 9. Dynamic Server Discovery . . . . . . . . . . . . . . . . . . . 22
9.2 Session Key List Generation . . . . . . . . . . . . . . . 21 10. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . . . . 23
9.3 Sending Messages . . . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.4 Receiving Messages . . . . . . . . . . . . . . . . . . . . 21 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.5 Autokey Protocol Exchanges . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
10. Dynamic Server Discovery . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11. NTP Control Messages . . . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.1 NTP Control Message Format . . . . . . . . . . . . . . . 26 14.2. Informative References . . . . . . . . . . . . . . . . . . 25
11.2 Status Words . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. NTP Control Messages . . . . . . . . . . . . . . . . 27
11.2.1 System Status Word . . . . . . . . . . . . . . . . . 28 A.1. NTP Control Message Format . . . . . . . . . . . . . . . . 28
11.2.2 Peer Status Word . . . . . . . . . . . . . . . . . . 29 A.2. Status Words . . . . . . . . . . . . . . . . . . . . . . . 30
11.2.3 Clock Status Word . . . . . . . . . . . . . . . . . 31 A.2.1. System Status Word . . . . . . . . . . . . . . . . . . 31
11.2.4 Error Status Word . . . . . . . . . . . . . . . . . 32 A.2.2. Peer Status Word . . . . . . . . . . . . . . . . . . . 33
11.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . 33 A.2.3. Clock Status Word . . . . . . . . . . . . . . . . . . 34
12. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . . . 35 A.2.4. Error Status Word . . . . . . . . . . . . . . . . . . 35
13. Security Considerations . . . . . . . . . . . . . . . . . . 36 A.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 36
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
15. Other Considerations . . . . . . . . . . . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . . . 40
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
17.1 Normative References . . . . . . . . . . . . . . . . . . 39
17.2 Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . 42
1. Introduction 1. Introduction
The Network Time Protocol Version 3 (NTPv3) specified in [1] has been The Network Time Protocol Version 3 (NTPv3) [1] has been widely used
widely used to synchronize computer clocks in the global Internet. to synchronize computer clocks in the global Internet. It provides
It provides comprehensive mechanisms to access national time and comprehensive mechanisms to access national time and frequency
frequency dissemination services, organize the NTP subnet of servers dissemination services, organize the NTP subnet of servers and
and clients and adjust the system clock in each participant. In most clients and adjust the system clock in each participant. In most
places of the Internet of today, NTP provides accuracies of 1-50 ms, places on the Internet of today, NTP provides accuracies of 1-50 ms,
depending on the characteristics of the synchronization source and depending on the characteristics of the synchronization source and
network paths. network paths.
NTP is designed for use by clients and servers with a wide range of NTP is designed for use by clients and servers with a wide range of
capabilities and over a wide range of network jitter and clock capabilities. Thus, the Simple Network Time Protocol Version 4
frequency wander characteristics. Many users of NTP in the Internet (SNTPv4) as described in [2] was developed for platforms that cannot
of today use a software distribution available from www.ntp.org. The afford the size and complexity of NTP as a whole.
distribution, which includes the full suite of NTP options,
mitigation algorithms and security schemes, is a relatively complex,
real-time application. While the software has been ported to a wide
variety of hardware platforms ranging from personal computers to
supercomputers, its sheer size and complexity is not appropriate for
many applications. This facilitated the development of the Simple
Network Time Protocol Version 4 (SNTPv4) as described in [2].
Since the standardization of NTPv3, there has been significant Since the standardization of NTPv3, there has been significant
development which has led to Version 4 of the Network Time Protocol development which has led to Version 4 of the Network Time Protocol
(NTPv4). This document describes NTPv4, which introduces new (NTPv4). This document describes NTPv4, which introduces new
functionality to NTPv3 as described in RFC 1305, and functionality functionality to NTPv3 as described in RFC 1305, and functionality
expanded from that of SNTPv4 as described in RFC 2030 (SNTPv4 is a expanded from that of SNTPv4 as described in RFC 4330 (SNTPv4 is a
subset of NTPv4). subset of NTPv4). This document obsoletes RFC 4330.
When operating with current and previous versions of NTP and SNTP, When operating with current and previous versions of NTP and SNTP,
NTPv4 requires no changes to the protocol or implementations now NTPv4 requires no changes to the protocol or implementations now
running or likely to be implemented specifically for future NTP or running or likely to be implemented specifically for future NTP or
SNTP versions. The NTP and SNTP packet formats are the same and the SNTP versions. The NTP and SNTP packet formats are the same and the
arithmetic operations to calculate the client time, clock offset and arithmetic operations to calculate the client time, clock offset and
round trip delay are the same. To a NTP or SNTP server, NTP and SNTP round trip delay are the same. To a NTP or SNTP server, NTP and SNTP
clients are indistinguishable; to a NTP or SNTP client, NTP and SNTP clients are indistinguishable; to a NTP or SNTP client, NTP and SNTP
servers are indistinguishable. servers are indistinguishable.
An important provision in this memo is the interpretation of certain An important provision in this memo is the interpretation of certain
NTP header fields which provide for IPv6 and OSI addressing. The NTP header fields which provide for IPv6 [3]and OSI [4] addressing.
only significant difference between the NTPv3 and NTPv4 header The only significant difference between the NTPv3 and NTPv4 header
formats is the four-octet Reference Identifier field, which is used formats is the four-octet Reference Identifier field, which is used
primarily to detect and avoid synchronization loops. In all NTP and primarily to detect and avoid synchronization loops. In all NTP and
SNTP versions providing IPv4 addressing, primary servers use a four- SNTP versions providing IPv4 addressing, primary servers use a four-
character ASCII reference clock identifier in this field, while character ASCII reference clock identifier in this field, while
secondary servers use the 32-bit IPv4 address of the synchronization secondary servers use the 32-bit IPv4 address of the synchronization
source. In NTPv4 providing IPv6 and OSI addressing, primary servers source. In NTPv4 providing IPv6 and OSI addressing, primary servers
use the same clock identifier, but secondary servers use the first 32 use the same clock identifier, but secondary servers use the first 32
bits of the MD5 hash of the IPv6 or NSAP address of the bits of the MD5 hash of the IPv6 or NSAP address of the
synchronization source. A further use of this field is when the synchronization source. A further use of this field is when the
server sends a kiss-o'-death message documented later in this server sends a kiss-o'-death message documented later in this
document. document.
In the case of OSI, the Connectionless Transport Service (CLTS) is In the case of OSI, the Connectionless Transport Service (CLTS) is
used as in [3]. Each NTP packet is transmitted as the TS- Userdata used as in [5]. Each NTP packet is transmitted as the TS- Userdata
parameter of a T-UNITDATA Request primitive. Alternately, the header parameter of a T-UNITDATA Request primitive. Alternately, the header
can be encapsulated in a TPDU which itself is transported using UDP, can be encapsulated in a TPDU which itself is transported using UDP,
as described in [4]. It is not advised that NTP be operated at the as described in [6]. It is not advised that NTP be operated at the
upper layers of the OSI stack, such as might be inferred from [5], as upper layers of the OSI stack, such as might be inferred from [7], as
this could seriously degrade accuracy. With the header formats this could seriously degrade accuracy. With the header formats
defined in this memo, it is in principle possible to interwork defined in this memo, it is, in principle, possible to interwork
between servers and clients of one protocol family and another, between servers and clients of one protocol family and another,
although the practical difficulties may make this inadvisable. although the practical difficulties may make this inadvisable.
In the following, indented paragraphs such as this one contain
information not required by the formal protocol specification, but
considered good practice in protocol implementations.
This document is organized as follows.Section 2 describes the NTP This document is organized as follows.Section 2 describes the NTP
timestamp format and Section 3 the NTP message format. Section 4 timestamp format and Section 3 the NTP message format. Section 4
provides general NTP protocol details, with the subset SNTP described provides general NTP protocol details, with the subset SNTP described
in Section 5. This is followed by specific sections on Server in Section 5. This is followed by specific sections on Server
(Section 6), Client(Section 7), and Symmetric Peer(Section 8) modes (Section 6), Client(Section 7), and Symmetric Peer(Section 8) modes
of operation.Section 9 summarizes the optional security mechanisms of operation. Section 9 defines the new mechanism for server
present within the NTPv4 protocol. Section 10 defines the new discovery. describes the control and management mechanism for NTP.
mechanism for server discovery. Section 11 describes the control and Section 10 describes the kiss-o'-death message, whose functionality
management mechanism for NTP. Section 12 describes the kiss-o'-death is similar to the ICMP Source Quench and ICMP Destination Unreachable
message, whose functionality is similar to the ICMP Source Quench and messages. Section 11 presents NTPv4 security considerations and
ICMP Destination Unreachable messages. Section 13 presents NTPv4 Section 12 discusses IANA Considerations.Appendix A presents optional
security considerations and Section 14 discusses IANA Considerations. NTP control messages.
Finally, Section 15 presents various other considerations when
implementing and/or configuring NTPv4.
NTPv4 is hereafter referred to simply as NTP, unless explicitly NTPv4 is hereafter referred to simply as NTP, unless explicitly
noted. noted.
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [8].
2. NTP Timestamp 2. NTP Timestamp
NTPv4 uses the standard NTP timestamp format described in RFC 1305. There are three NTP formats used to represent time values: a 128-bit
date format, a 64-bit timestamp format, and a 32-bit short format.
NTP data are specified as integer or fixed-point quantities, with NTP data are specified as integer or fixed-point quantities, with
bits numbered in big-endian fashion from 0 starting at the left or bits numbered in big-endian fashion from 0 starting at the left or
most significant end. Unless specified otherwise, all quantities are most significant end. Unless specified otherwise, all quantities are
unsigned and may occupy the full field width with an implied 0 unsigned and may occupy the full field width with an implied 0
preceding bit 0. preceding bit 0. Note that dates cannot be produced by NTP, but can
rather be obtained from external means and conveyed via the protocol.
Date values are represented in twos compliment arithmetic relative to
the base date of 0628:16h 7 February 2036 UTC (when all 128 bits are
zero). Values greater than zero represent times after the base date;
values less than zero represent times before the base date. Dates
are signed values. Timestamps are signed values. A value of zero is
a special case representing unknown or unsynchronized time.
NTP timestamps are represented as a 64-bit unsigned fixed-point Figure 1 illustrates the three NTP time formats.
number, in seconds relative to 0h on 1 January 1900. The integer
part is in the first 32 bits and the fraction part in the last 32 0 1 2 3
bits. In the fraction part, the non-significant low order bits are 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
not specified and ordinarily set to 0. The NTP timestamp format is +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
defined as: | Seconds | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Short Format
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds | | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction | | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Timestamp Format
It is advisable to fill the non-significant low order bits of the 0 1 2 3
timestamp with a random, unbiased bitstring, both to avoid systematic 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
roundoff errors and as a means of loop detection and replay detection +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(see below). It is important that the bitstring be unpredictable by | Era Number |
a intruder. One way of doing this is to generate a random 128-bit +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
bitstring at startup. After that, each time the system clock is read | Era Offset |
the string consisting of the timestamp and bitstring is hashed with +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the MD5 algorithm, then the non-significant bits of the timestamp are | |
copied from the result. | Fraction |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Date Format
The NTP format allows convenient multiple-precision arithmetic and Figure 1: NTP Timestamp Format
conversion to UDP/TIME message (seconds), but does complicate the
conversion to ICMP Timestamp message (milliseconds) and Unix time
values (seconds and microseconds or seconds and nanoseconds). The
maximum number that can be represented is 4,294,967,295 seconds with
a precision of about 232 picoseconds, which should be adequate for
even the most exotic requirements.
Note that, since some time in 1968 (second 2,147,483,648) the most Note that, since some time in 1968 (second 2,147,483,648) the most
significant bit (bit 0 of the integer part) has been set and that the significant bit (bit 0 of the integer part) has been set and that the
64-bit field will overflow some time in 2036 (second 4,294,967,296). 64-bit field will overflow some time in 2036 (second 4,294,967,296).
There will exist a 232-picosecond interval, henceforth ignored, every There will exist a 232-picosecond interval, henceforth ignored, every
136 years when the 64-bit field will be 0, which by convention is 136 years when the 64-bit field will be 0, which by convention is
interpreted as an invalid or unavailable timestamp. interpreted as an invalid or unavailable timestamp.
If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time
is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not
set, the time is in the range 2036-2104 and UTC time is reckoned from set, the time is in the range 2036-2104 and UTC time is calculated
6h 28m 16s UTC on 7 February 2036. Note that when calculating the from 6h 28m 16s UTC on 7 February 2036. Note that when calculating
correspondence, 2000 is a leap year and leap seconds are not included the correspondence, 2000 is a leap year and leap seconds are not
in the reckoning. included in the reckoning.
3. NTP Message Formats 3. NTP Message Formats
Both NTP and SNTP are layered above of the User Datagram Protocol Both NTP and SNTP are layered above the User Datagram Protocol (UDP)
(UDP) [6], which itself is layered on the Internet Protocol (IP) [7] [9], which itself is layered on the Internet Protocol (IP) [10] [3].
[8]. The structure of the IP and UDP headers is described in the The structure of the IP and UDP headers is described in the cited
cited specification documents and will not be detailed further here. specification documents and will not be detailed further here. The
The UDP port number assigned to NTP is 123, which should be used in UDP port number assigned to NTP is 123, which MUST be used in both
both the Source Port and Destination Port fields in the UDP header. the Source Port and Destination Port fields in the UDP header. The
The remaining UDP header fields should be set as described in the remaining UDP header fields should be set as described in the
specification. specification.
Below is a description of the NTPv4 message format, which follows the Figure 2 provides a description of the NTPv4 message format. This
IP and UDP headers. This format is identical to that described in format is identical to that described in RFC 1305, with the exception
RFC 1305, with the exception of the contents of the reference of the contents of the reference identifier field and optional
identifier field. The header fields are defined as: extension fields. The header fields are defined in Figure 2.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Strat | Poll | Prec | |LI | VN |Mode | Strat | Poll | Prec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay | | Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion | | Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 46 skipping to change at page 7, line 46
| | | |
+ Extension Field 2 (Optional) + + Extension Field 2 (Optional) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. Authentication . . Authentication .
. (Optional) (160 bits) . . (Optional) (160 bits) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1 Leap Indicator (LI) Figure 2: NTPv4 Message Format
3.1. Leap Indicator (LI)
This is a two-bit field indicating an impending leap second to be This is a two-bit field indicating an impending leap second to be
inserted in the NTP timescale. The bits are set before 23:59 on the inserted in the NTP timescale. The bits are set before 23:59 on the
day of insertion and reset after 00:00 on the following day. This day of insertion and reset after 00:00 on the following day. This
causes the number of seconds (rollover interval) in the day of causes the number of seconds (rollover interval) in the day of
insertion to be increased or decreased by one. In the case of insertion to be increased or decreased by one. A leap second is
primary servers the bits are set by operator intervention, while in inserted or deleted in the timescale on the last day of June or
the case of secondary servers the bits are set by the protocol. The December. The possible values of the LI field, and corresponding
possible values of the LI field, and corresponding meanings, are as meanings, are given in Table 1.
follows:
+----+------------------------------------------+ +----+--------------------------------------------+
| LI | Meaning | | LI | Meaning |
+----+------------------------------------------+ +----+--------------------------------------------+
| 0 | no warning | | 0 | no warning |
| 1 | last minute has 61 seconds | | 1 | last minute of the day has 61 seconds |
| 2 | last minute has 59 seconds | | 2 | last minute of the day has 59 seconds |
| 3 | alarm condition (clock not synchronized) | | 3 | alarm condition (clock never synchronized) |
+----+------------------------------------------+ +----+--------------------------------------------+
Table 1: Length Indicator Field Values
On startup, servers set this field to 3 (clock not synchronized) and On startup, servers set this field to 3 (clock not synchronized) and
set this field to some other value when synchronized to the primary set this field to some other value when synchronized to the primary
reference clock. Once set to other than 3, the field is never set to reference clock. Once set to other than 3, the field is never set to
that value again, even if all synchronization sources become that value again, even if all synchronization sources become
unreachable or defective. unreachable or defective.
3.2 Version (VN) 3.2. Version (VN)
This is a three-bit integer indicating the NTP/SNTP version number, This is a three-bit integer indicating the NTP/SNTP version number,
currently 4. If necessary to distinguish between IPv4, IPv6 and OSI, set to 4 for NTPv4. If necessary to distinguish between IPv4, IPv6
the encapsulating context must be inspected. and OSI, the encapsulating context must be inspected.
3.3 Mode 3.3. Mode
This is a three-bit number indicating the protocol mode. The values This is a three-bit number indicating the protocol mode. The values
are defined as follows: are defined in Table 2.
+------+----------------------------------+ +------+--------------------------+
| Mode | Meaning | | Mode | Meaning |
+------+----------------------------------+ +------+--------------------------+
| 0 | reserved | | 0 | reserved |
| 1 | symmetric active | | 1 | symmetric active |
| 2 | symmetric passive | | 2 | symmetric passive |
| 3 | client | | 3 | client |
| 4 | server | | 4 | server |
| 5 | broadcast | | 5 | broadcast |
| 6 | reserved for NTP control message | | 6 | NTP control message |
| 7 | reserved for private use | | 7 | reserved for private use |
+------+----------------------------------+ +------+--------------------------+
In unicast mode or discovery mode, the client sets this field to 3 Table 2: Mode Field Values
(client) in the request and the server sets it to 4 (server) in the Mode 0 is reserved. Modes 1 and 2 are intended for use by symmetric
reply. In broadcast mode, the server sets this field to 5 peers who set this mode to 1 or 2 depending on whether it is active
(broadcast). or passive mode. In unicast mode or discovery mode, the client sets
this field to 3 (client) in the request and the server sets it to 4
(server) in the reply. In broadcast mode, the server sets this field
to 5 (broadcast). A mode type of 6 is reserved for NTP control
messages. Mode 7 is reserved for private usage.
3.4 Stratum (Strat) 3.4. Stratum (Strat)
This is a eight-bit unsigned integer indicating the stratum. This This is a eight-bit unsigned integer indicating the stratum. This
field is significant only in SNTP server messages, where the values field is significant only in SNTP server messages, where the values
are defined as follows: are defined in Table 3.
+---------+-------------------------------------------------------+ +---------+-------------------------------------------------------+
| Stratum | Meaning | | Stratum | Meaning |
+---------+-------------------------------------------------------+ +---------+-------------------------------------------------------+
| 0 | kiss-o'-death message | | 0 | kiss-o'-death message |
| 1 | primary reference (e.g., synchronized by radio clock) | | 1 | primary reference (e.g., synchronized by radio clock) |
| 2-15 | secondary reference (synchronized by NTP or SNTP) | | 2-255 | secondary reference (synchronized by NTP or SNTP) |
| 16-255 | reserved |
+---------+-------------------------------------------------------+ +---------+-------------------------------------------------------+
3.5 Poll Interval (Poll) Table 3: Stratum Field Values
This is an eight-bit unsigned integer used as an exponent of two, 3.5. Poll Interval (Poll)
where the resulting value is the maximum interval between successive
messages in seconds. This field is significant only in SNTP server
messages, where the values range from 4 (16 s) to 17 (131,072 s -
about 36 h).
3.6 Precision (Prec) This is an eight-bit unsigned integer indicating the maximum interval
between successive messages, in log2 seconds. A client SHOULD NOT
use a poll interval less than 15 seconds, except at initial startup
when it MAY send a sequence of 8 packets at 1 second intervals to
provide initial synchronization of the clients with each server. A
client SHOULD increase the poll interval as performance permits and
especially if the server does not respond within a reasonable time.
This is an eight-bit signed integer used as an exponent of two, where 3.6. Precision (Prec)
the resulting value is the precision of the system clock in seconds.
This field is significant only in server messages, where the values
range from -6 for mains-frequency clocks to -20 for microsecond
clocks found in some workstations.
3.7 Root Delay This is an eight-bit signed integer indicating the precision of the
system clock in log2 seconds. Precision is normally determined when
the service is established as the minimum number of iterations of the
time to read the system clock. As an example, a value of -18
corresponds to a precision of about one microsecond.
3.7. Root Delay
This is a 32-bit signed fixed-point number indicating the total This is a 32-bit signed fixed-point number indicating the total
roundtrip delay to the primary reference source, in seconds with roundtrip delay to the primary reference source, in 32-bit NTP short
fraction point between bits 15 and 16. Note that this variable can format. Note that this variable can take on both positive and
take on both positive and negative values, depending on the relative negative values, depending on the relative time and frequency
time and frequency offsets. This field is significant only in server offsets. This field is significant only in server messages, where
messages, where the values range from negative values of a few the values range from negative values of a few milliseconds to
milliseconds to positive values of several hundred milliseconds. positive values of several hundred milliseconds.
3.8 Root Dispersion 3.8. Root Dispersion
This is a 32-bit unsigned fixed-point number indicating the nominal This is a 32-bit unsigned fixed-point number indicating the nominal
error relative to the primary reference source, in seconds with error relative to the primary reference source in seconds, in 32-bit
fraction point between bits 15 and 16. This field is significant NTP short format.
only in server messages, where the values range from zero to several
hundred milliseconds.
3.9 Reference Identifier 3.9. Reference Identifier
This is a 32-bit bitstring identifying the particular reference This is a 32-bit bitstring identifying the particular reference
source. This field is significant only in server messages, where for source. The interpretation of this field depends on the value in the
stratum 0 (kiss-o'-death message) and 1 (primary server), the value stratum field. For stratum 0, this is a four-character ASCII string,
is a four-character ASCII string, left justified and zero padded to referred to as a 'kiss code' and is used for debugging and monitoring
32 bits. For IPv4 secondary servers,the value is the 32-bit IPv4 purposes. For stratum 1, this is a four-octet, left-justified, zero-
address of the synchronization source. For IPv6 and OSI secondary padded ASCII string assigned to the reference source. Above stratum
servers, the value is the first 32 bits of the MD5 hash of the IPv6 1 (secondary servers and clients), this is the reference identifier
or NSAP address of the synchronization source. of the server. If employing IPv4, the value is the 32-bit IPv4
address of the synchronization source. For IPv6 and OSI, the value
is the first 32 bits of the MD5 hash of the IPv6 or NSAP address of
the synchronization source. The fASCII identifiers that are
currently defined are given in Table 4.
Primary (stratum 1) servers set this field to a code identifying the Primary (stratum 1) servers set this field to a code identifying the
external reference source according to the below table. external reference source according to Table 4.
+------+----------------------------------------------------------+ +-------+----------------------------------------------------+
| Code | External Reference Source | | Code | External Reference Source |
+------+----------------------------------------------------------+ +-------+----------------------------------------------------+
| LOCL | uncalibrated local clock | | GOES | Geosynchronous Orbit Environment Satellite |
| CESM | calibrated Cesium clock | | GPS | Global Position System |
| RBDM | calibrated Rubidium clock | | PPS | Generic pulse-per-second |
| PPS | calibrated quartz clock or other pulse-per-second source |
| IRIG | Inter-Range Instrumentation Group | | IRIG | Inter-Range Instrumentation Group |
| ACTS | NIST telephone modem service | | WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz |
| USNO | USNO telephone modem service | | DCF77 | LF Radio DCF77 Mainflingen, DE 77.5 kHz |
| PTB | PTB (Germany) telephone modem service | | HBG | LF Radio HBG Prangins, HB 75 kHz |
| TDF | Allouis (France) Radio 164 kHz | | MSF | LF Radio MSF Rugby, UK 60 kHz |
| DCF | Mainflingen (Germany) Radio 77.5 kHz | | JJY | LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz |
| MSF | Rugby (UK) Radio 60 kHz | | LORC | MF Radio LORAN C 100 kHz |
| WWV | Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz | | TDF | MF Radio Allouis, FR 162 kHz |
| WWVB | Boulder (US) Radio 60 kHz | | CHU | HF Radio CHU Ottawa, Ontario |
| WWVH | Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz | | WWV | HF Radio WWV Ft. Collins, CO |
| CHU | Ottawa (Canada) Radio 3330, 7335, 14670 kHz | | WWVH | HF Radio WWVH Kauai, HI |
| LORC | LORAN-C radionavigation system | | NIST | NIST telephone modem |
| OMEG | OMEGA radionavigation system | | USNO | USNO telephone modem |
| GPS | Global Positioning Service | | PTB | European telephone modem |
+------+----------------------------------------------------------+ +-------+----------------------------------------------------+
If the external reference is one of those listed, the associated code Table 4: Currently-defined Reference Identifiers
should be used. Codes for sources not listed can be contrived as
appropriate.
In previous NTP and SNTP secondary servers and clients this field was If the external reference is one of those listed, the associated code
often used to walk-back the synchronization subnet to the root should be used. Codes for sources not listed can be created as
(primary server) for management purposes. appropriate (see IANA Considerations section of this document).
3.10 Reference Timestamp 3.10. Reference Timestamp
This field is significant only in server messages, where the value is This is a 64 bit signed integer indicating the time when the system
the time at which the system clock was last set or corrected, in 64- clock was last set or correctetd, in 64-bit NTP timestamp format.
bit timestamp format.
3.11 Originate Timestamp 3.11. Originate Timestamp
This is the time at which the request departed the client for the This is the time at which the request departed the client for the
server, in 64-bit timestamp format. server, in 64-bit NTP timestamp format.
3.12 Receive Timestamp 3.12. Receive Timestamp
This is the time at which the request arrived at the server or the This is the time at which the request arrived at the server or the
reply arrived at the client, in 64-bit timestamp format. reply arrived at the client, in 64-bit NTP timestamp format.
3.13 Transmit Timestamp 3.13. Transmit Timestamp
This is the time at which the request departed the client or the This is the time at which the request departed the client or the
reply departed the server, in 64-bit timestamp format. reply departed the server, in 64-bit NTP timestamp format.
3.14 NTPv4 Extension Fields 3.14. NTPv4 Extension Fields
NTPv4 defines new extension field formats. These fields are NTPv4 defines new extension field formats. The minimum extension
processed in order and may be transmitted with or without value field length is 8 octets. The format of the NTP extension field is
fields. The last field is padded to a 64-bit boundary, all others given in Figure Figure 3.
fields are padded to 32-bit boundaries. The field length is for all
payload and padding.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type | Length | | Field Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 31 skipping to change at page 12, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | | Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. Signature . . Signature .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) | | Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.15 Authentication (optional) Figure 3: NTP Extension Field Format
The authentication field format is defined as: The Field Type field is a 16-bit integer which indicates the type of
extension message contained within the extension field.
The Length field is a 16-bit integer indicates the length of the
entire extension field in octets, including the Length and Padding
fields.
The 32-bit Association ID field is set by clients to the value
previously received from the server or 0 otherwise. The server sets
the Association ID field when sending a response as a handle for
subsequent exchanges. If the association ID value in a request does
not match the association ID of any association, the server returns
the request with the first two bits of the Field Type field set to 1.
The Timestamp and Filestamp 32-bit fields carry the seconds field of
an NTP timestamp. The Timestamp field establishes the signature
epoch of the data field in the message, while the filestamp
establishes the generation epoch of the file that ultimately produced
the data.
The 32-bit Value Length field indicates the length of the Value field
in octets. The minimum length of the Value field is 0.
The 32-bit Signature Length field indicates the length of the
Signature field in octets.
Zero padding is applied, as necessary, to extend the extension field
to a word (4-octet) boundary. If multiple extension fields are
present, the last extension field is zero-padded to a double-word (8
octet) boundary.
3.15. Authentication (optional)
NTPv4 provides an optional 160-bit Authentication field. When
implemented, the 32-bit Key Identifier and 128-bit Message Digest
fields contain the Message Authentication Code (MAC) information
which uses an MD5 cryptosum of NTP header plus extension fields. The
authentication field format is shown in Figure Figure 4.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier | | Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Message Digest + + Message Digest +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the NTP authentication scheme is implemented, the 16-bit Key Figure 4: NTP Authentication Field
Identifier and 128-bit Message Digest fields contain the Message
Authentication Code (MAC) information which uses an MD5 cryptosum of The 32-bit Key Identifier is an integer identifying the 128-bit
NTP header plus extension fields. private key used to generate the MAC. The Message Digest field
contains the MD5 Message Digest. In NTPv4, the presence of one or
more extension fields requires the presence of an authentication
field. The presence of the Authentication field and extension fields
is determined from the Length field.
The Key Identifier is initialized to zero at the start of an
association. The type of association then determines the key
identifier. If the association is active (modes 1, 3, 5) the key is
determined from the system key identifier. If the association is
passive (modes 2, 4) the key is determined from the peer key
identifier, if the authentic bit is set (see [1]), or as the default
key (zero) otherwise.
4. NTP Protocol Operation 4. NTP Protocol Operation
The NTP protocol defines three operational roles, Client, Server, and The NTP protocol defines three operational roles, Client, Server, and
Symmetric Peer. Clients request or receive time unsolicited from Symmetric Peer. Clients request or receive time from Servers
Servers. Servers respond to requests or send periodic time updates (solicited or unsolicited). Servers respond to requests or send
to Clients. Symmetric Peers exchange time data bidirectionally. A periodic time updates to Clients. Symmetric Peers exchange time data
given NTP implementation can operate in any or all of these modes. bidirectionally. A given NTPv4 implementation can operate in any or
all of these modes.
NTP messages make use of two different communication modes, one to NTP messages make use of two different communication modes, one to
one and one to many, commonly referred to as unicast and broadcast. one and one to many, commonly referred to as unicast and broadcast.
For the purposes of this document, the term broadcast is interpreted For the purposes of this document, the term broadcast is interpreted
to mean any available one to many mechanism. For IPv4 this equates to mean any available one to many mechanism. For IPv4 this equates
to either IPv4 broadcast or IPv4 multicast. For IPv6 this equates to to either IPv4 broadcast or IPv4 multicast. For IPv6 this equates to
IPv6 multicast. For OSI this XXXXX. For this purpose, IANA has IPv6 multicast. For this purpose, IANA has allocated the IPv4
allocated the IPv4 multicast address 224.0.1.1 and the IPv6 multicast multicast address 224.0.1.1 and the IPv6 multicast address ending
address ending :101, with prefix determined by scoping rules. The :101, with prefix determined by scoping rules.
NTP broadcast address for OSI has yet to be determined.
It is important to adjust the time-to-live (TTL) field in the IP Except in broadcast mode, an NTP association is formed when two peers
header of multicast messages to a reasonable value in order to exchange messages and one or both of them create and maintain an
limit the network resources used by this (and any other) multicast instantiation of the protocol machine, called an association. The
service. Only multicast clients in scope will receive multicast association can operate in one of five modes as indicated by the
server messages. Only cooperating anycast servers in scope will host- mode variable (peer.mode) (see [1] for a description of the NTP
reply to a client request. The engineering principles which variables): symmetric active, symmetric passive, client, server and
determine the proper values to be used are beyond the scope of broadcast, which are defined as follows:
this memo.
While not integral to the NTP specification, it is intended that Symmetric Active (1): A host operating in this mode sends periodic
IP broadcast addresses will be used primarily in IP subnets and messages regardless of the reachability state or stratum of its peer.
LAN segments including a fully functional NTP server with a number By operating in this mode the host announces its willingness to
of dependent NTP broadcast clients on the same subnet, while IP synchronize and be synchronized by the peer.
multicast group addresses will be used only in cases where the TTL
is engineered specifically for each service domain. Symmetric Passive (2): This type of association is ordinarily created
upon arrival of a message from a peer operating in the symmetric
active mode and persists only as long as the peer is reachable and
operating at a stratum level less than or equal to the host;
otherwise, the association is dissolved. However, the association
will always persist until at least one message has been sent in
reply. By operating in this mode the host announces its willingness
to synchronize and be synchronized by the peer.
Client (3): A host operating in this mode sends periodic messages
regardless of the reachability state or stratum of its peer. By
operating in this mode the host announces its willingness to be
synchronized by, but not to synchronize the peer.
Server (4): This type of association is ordinarily created upon
arrival of a client request message and exists only in order to reply
to that request, after which the association is dissolved. By
operating in this mode the host announces its willingness to
synchronize, but not to be synchronized by the peer.
Broadcast (5): A host operating in this mode sends periodic messages
regardless of the reachability state or stratum of the peers. By
operating in this mode the host announces its willingness to
synchronize all of the peers, but not to be synchronized by any of
them.
NTP messages are layered on top of UDP. All messages MUST be sent NTP messages are layered on top of UDP. All messages MUST be sent
with a destination port of 123, and SHOULD be sent with a source port with a destination port of 123, and SHOULD be sent with a source port
of 123. of 123.
5. SNTP Protocol Operation The on-wire protocol uses four timestamps numbered T1 through T4 and
three state variables org, rec, and xmt, as shown in Figure Figure 5,
where T1 corresponds to the Reference Timestamp T2 corresponds to the
Originate Timestamp, T3 corresponds to the Receive Timestamp, and T4
corresponds to the Transmit Timestamp.
SNTP operates using the same message formats, addresses, and ports as t2 t3 t6 t7
NTP. However, it is stateless, operating only in the Client or +---------+ +---------+ +---------+ +---------+
Server roles. Thus it is compatible with, and a subset of, NTP. T1 | 0 | | t2 | | t4 | | t6 |
+---------+ +---------+ +---------+ +---------+
T2 | 0 | | t1 | | t3 | | t5 | Packet
+---------+ +---------+ +---------+ +---------+ Variables
T3 |t2=clock | | t2 | |t6=clock | | t6 |
+---------+ +---------+ +---------+ +---------+
T4 | t1 | |t3=clock | | t5 | |t7=clock |
+---------+ +---------+ +---------+ +---------+
Peer B
+---------+ +---------+ +---------+ +---------+
org | t1 | | t1 | | T3<>t1? | | t5 |
+---------+ +---------+ +---------+ +---------+ State
rec | t2 | | t2 | | t6 | | t6 | Variables
+---------+ +---------+ +---------+ +---------+
xmt | 0 | | t3 | | T1<>t3? | | t7 |
+---------+ +---------+ +---------+ +---------+
Without the complexity and state required by the Symmetric Peer, SNTP t2 t3 t6 t7
is apropriate for devices which require a significantly smaller ---------------------------------------------------------
resource footprint. Since a SNTP server ordinarily does not /\ \ /\ \
implement the full suite of grooming and mitigation algorithms / \ / \
intended to support redundant servers and diverse network paths, a / \ / \
SNTP server should be operated only in conjunction with a source of / \/ / \/
external synchronization, such as a reliable radio clock or telephone ---------------------------------------------------------
modem. In this case it operates as a primary (stratum 1) server. t1 t4 t5 t8
Note that SNTP servers normally operate as primary (stratum 1) t1 t4 t5 t8
servers. While operating at higher strata (up to 15) and at the +---------+ +---------+ +---------+ +---------+
same time synchronizing to an external source such as a GPS T1 | 0 | | t2 | | t4 | | t6 |
receiver is not forbidden, this is strongly discouraged. +---------+ +---------+ +---------+ +---------+
T2 | 0 | | t1 | | t3 | | t5 | Packet
+---------+ +---------+ +---------+ +---------+ Variables
T3 | 0 | |t4=clock | | t4 | |t8=clock |
+---------+ +---------+ +---------+ +---------+
T4 |t1=clock | | t3 | |t5=clock | | t7 |
+---------+ +---------+ +---------+ +---------+
Peer A
+---------+ +---------+ +---------+ +---------+
org | 0 | | T3<>0? | | t3 | | T3<>t3? |
+---------+ +---------+ +---------+ +---------+ State
rec | 0 | | t4 | | t4 | | t8 | Variables
+---------+ +---------+ +---------+ +---------+
xmt | t1 | | T1=t1? | | t5 | | T1<>t5? |
+---------+ +---------+ +---------+ +---------+
Figure 5: NTPState
This figure shows the most general case, where each of two peers, A
and B, independently measure the offset and delay relative to the
other. For illustrative purposes, the individual timestamp values
are shown in lower case with subscripts indicating the order of
transmission and reception. In the figure, the first packet
transmitted by A contains only the transmit timestamp T4 with value
t1. B receives the packet at t2 and saves the originate timestamp T2
with value t1 in state variable org and the receive timestamp T3 with
value t2 in state variable rec. Afterwards, B sends a packet to A
containing the org and rec state variables in T2 and T1 respectively
and additionally the transmit timestamp T4 with value t3, which is
saved in the xmt state variable. When this packet arrives at A the
packet header variables T1, T2, T3, and T4 represent the four
timestampes necessary to compute the offset and delay of B relative
to A.
Before the A state variables are updated, two sanity checks are
performed in order to protect against duplicate or invalid packets.
A packet is a duplicate if the transmit timestamp T4 in the packet
matches the xmt state variable. A packet is invalid if the origin
timestamp T2 in the packet does not match the org state variable. In
either of these cases the state variables are updated, but the packet
is discarded.
The general rules that govern the updating of state variables and
packet variables are given in Figure 6.
+-------------------------------------------------------+
| Receive | Transmit |
+-------------------------------------------------------+
| org=T4 | org=unchanged |
| rec=Time of Receipt | rec=unchanged |
| xmt=unchanged | xmt=Time of transmission |
| | |
| T1=Received T3 | T1=rcv |
| T2=Received T2 | T2=org |
| T3=rec | T3=unchanged |
| T4=Received T4 | T4=xmt |
+-------------------------------------------------------+
Figure 6: Relationship between NTP State Variables and NTP Packet
Variables
5. SNTP Protocol Operation
SNTP operates using the same message formats, addresses, and ports as
NTP. However, it is stateless, operating only in the client or
server roles. Thus it is compatible with, and a subset of, NTP.
6. NTP Server Operations 6. NTP Server Operations
Fundamentally, the NTP Server role consists of listening for client Fundamentally, the NTP Server role consists of listening for client
requests, and providing time and associated details as a response. requests, and providing time and associated details as a response.
Additionally, a Server can provide time and associated details Additionally, a server can provide time and associated details
periodically via a broadcast mechanism. An NTP server operating with periodically via a broadcast mechanism.
either an NTP or SNTP client of the same or previous versions retains
no persistent state.
An NTP server can communicate via unicast, broadcast, or both. A An NTP server can communicate via unicast, broadcast, or both. A
server receiving a unicast request (NTP mode 3), modifies fields in server receiving a unicast request (NTP mode 3), modifies fields in
the NTP header as described below, and sends a reply (NTP mode 4), the NTP header as described below, and sends a reply (NTP mode 4),
possibly using the same message buffer as the request. When possibly using the same message buffer as the request. When
operating in a broadcast mode, unsolicited messages (NTP mode 5) with operating in a broadcast mode, unsolicited messages (NTP mode 5) with
field values as described below are normally sent at intervals field values as described below are normally sent at intervals
ranging from 64 s to 1024 s, depending on the expected frequency ranging from 64 s to 1024 s, depending on the expected frequency
tolerance of the client clocks and the required accuracy. tolerance of the client clocks and the required accuracy.
skipping to change at page 16, line 5 skipping to change at page 18, line 38
LI field is set to one of the other three values and remains at the LI field is set to one of the other three values and remains at the
last value set even if the reference source becomes unreachable or last value set even if the reference source becomes unreachable or
turns faulty. turns faulty.
The Version (VN) is copied from the request packet, if responding to The Version (VN) is copied from the request packet, if responding to
a unicast request. For broadcast, this is set to 4. a unicast request. For broadcast, this is set to 4.
The Mode is set to Server (4) if in response to a unicast request. The Mode is set to Server (4) if in response to a unicast request.
For broadcast, this is set to Broadcast (5). For broadcast, this is set to Broadcast (5).
The Stratum field to the server's current stratum, if synchronized. The Stratum field is set to the server's current stratum, if
If synchronized to a reference source the Stratum field is set to 1. synchronized. If synchronized to a primary reference source the
If unsynchronized this field is set to 0. Stratum field is set to 1. If unsynchronized this field is set to 0.
The Poll field is coppied from the request, if responding to a The Poll field is coppied from the request, if responding to a
unicast request. For broadcast, this is set to the nearest integer unicast request. For broadcast, this is set to the nearest integer
base-2 logarithm of the poll interval. log2 of the poll interval.
The Precision field is set to reflect the maximum reading error of The Precision field is set to reflect the maximum reading error of
the system clock. For all practical cases it is computed as the the system clock. The Root Delay and Root Dispersion fields are set
negative base-2 logarithm of the number of significant bits to the to 0 for a primary server; optionally, the Root Dispersion field can
right of the decimal point in the NTP timestamp format. The Root be set to a value corresponding to the maximum error of the radio
Delay and Root Dispersion fields are set to 0 for a primary server; clock itself.
optionally, the Root Dispersion field can be set to a value
corresponding to the maximum expected error of the radio clock
itself.
If the server is synchronized to a reference source, the value of the If the server is synchronized to a reference source, the value of the
Reference ID is set to a four-character ASCII string identifying the Reference ID is set to a four-character ASCII string identifying the
source, left justified and zero padded to 32bits. For IPv4 secondary source, left justified and zero padded to 32bits. For IPv4 secondary
servers,the value is the 32-bit IPv4 address of the synchronization servers,the value is the 32-bit IPv4 address of the synchronization
source. For IPv6 and OSI secondary servers, the value is the first source. For IPv6 and OSI secondary servers, the value is the first
32 bits of the MD5 hash of the IPv6 or NSAP address of the 32 bits of the MD5 hash of the IPv6 or NSAP address of the
synchronization source. If unsynchronized, it is set to an ASCII synchronization source. If unsynchronized, it is set to an ASCII
error identifier. error identifier.
The timestamp fields in the server message are set as follows. If The timestamp fields in the server message are set as follows. If
the server is unsynchronized or first coming up, all timestamp fields the server is unsynchronized or first coming up, all timestamp fields
are set to zero with one exception. If the server is synchronized are set to zero with one exception. If the server is synchronized,
and up, the Transmit Timestamp field of the request is copied the Transmit Timestamp field of the request is copied unchanged to
unchanged to the Originate Timestamp field of the reply. It is the Originate Timestamp field of the reply.
important that this field be copied intact, as an NTP or SNTP client
uses it to avoid bogus messages.
If the server is synchronized, the Reference Timestamp is set to the If the server is synchronized, the Reference Timestamp is set to the
time the last update was received from the reference source. The time the last update was received from the reference source. The
Originate Timestamp field is set as in the unsynchronized case above. Originate Timestamp field is set as in the unsynchronized case above.
The Transmit Timestamp field are set to the time of day when the The Transmit Timestamp field is set to the time of day when the
message is sent. In broadcast messages the Receive Timestamp field message is sent. In broadcast messages the Receive Timestamp field
is set to zero and copied from the Transmit Timestamp field in other is set to zero and copied from the Transmit Timestamp field in other
messages. messages.
The following table summarizes these actions: Table 5 summarizes these actions.
+----------------+----------------+----------------+----------------+ +---------------+-----------+-------------------+-------------------+
| Field Name | Unicast | Unicast Reply | Broadcast | | Field Name | Unicast | Unicast Reply | Broadcast |
| | Request | | | | | Request | | |
+----------------+----------------+----------------+----------------+ +---------------+-----------+-------------------+-------------------+
| LI | ignore | as needed | as needed | | LI | ignore | as needed | as needed |
| VN | 1-4 | copied from | 4 | | VN | 1-4 | copied from | 4 |
| | | request | | | | | request | |
| Mode | 1 or 3 | 2 or 4 | 5 | | Mode | 1 or 3 | 2 or 4 | 5 |
| Stratum | ignore | 1 | 1 | | Stratum | ignore | 1 | 1 |
| Poll | ignore | copied from | log2 poll | | Poll | ignore | copied from | log2 poll |
| | | request | interval | | | | request | interval |
| Precision | ignore | -log2 server | -log2 server | | Precision | ignore | -log2 server | -log2 server |
| | | significant | significant | | | | significant bits | significant bits |
| | | bits | bits |
| Root Delay | ignore | 0 | 0 | | Root Delay | ignore | 0 | 0 |
| Root | ignore | 0 | 0 | | Root | ignore | 0 | 0 |
| Dispersion | | | | | Dispersion | | | |
| Reference | ignore | source ident | source ident | | Reference | ignore | source ident | source ident |
| Identifier | | | | | Identifier | | | |
| Reference | ignore | time of last | time of last | | Reference | ignore | time of last src. | time of last src. |
| Timestamp | | src. update | src. update | | Timestamp | | update | update |
| Originate | ignore | copied from | 0 | | Originate | ignore | copied from xmit | 0 |
| Timestamp | | xmit timestamp | | | Timestamp | | timestamp | |
| Receive | ignore | time of day | 0 | | Receive | ignore | time of day | 0 |
| Timestamp | | | | | Timestamp | | | |
| Transmit | (see text) | time of day | time of day | | Transmit | (see | time of day | time of day |
| Timestamp | | | | | Timestamp | text) | | |
| Authenticator | optional | optional | optional | | Authenticator | optional | optional | optional |
+----------------+----------------+----------------+----------------+ +---------------+-----------+-------------------+-------------------+
Table 5: NTP Server Message Field Population
Broadcast servers should respond to client unicast requests, as Broadcast servers should respond to client unicast requests, as
well as send unsolicited broadcast messages. Broadcast clients well as send unsolicited broadcast messages. Broadcast clients
may send unicast requests in order to measure the network may send unicast requests in order to measure the network
propagation delay between the server and client and then continue propagation delay between the server and client and then continue
operation in listen-only mode. However, broadcast servers may operation in listen-only mode. However, broadcast servers may
choose not to respond to unicast requests, so unicast clients choose not to respond to unicast requests, so unicast clients
should be prepared to abandon the measurement and assume a default should be prepared to abandon the measurement and assume a default
value for the delay value for the delay.
7. NTP Client Operations 7. NTP Client Operations
The role of an NTP client is to determine the current time (and The role of an NTP client is to determine the current time (and
associated information) from an NTP server. This can be done associated information) from an NTP server. This can be done
actively, by sending a unicast request to a configured server, or actively, by sending a unicast request to a configured server, or
passively by listening on a known address for periodic server passively by listening on a known address for periodic server
messages. messages.
An NTP client can operate in unicast or broadcast modes. In unicast An NTP client can operate in unicast or broadcast modes. In unicast
mode the client sends a request (NTP mode 3) to a designated unicast mode the client sends a request (NTP mode 3) to a designated unicast
server and expects a reply (NTP mode 4) from that server. In server and expects a reply (NTP mode 4) from that server. In
broadcast client mode it sends no request and waits for a broadcast broadcast client mode it sends no request and waits for a broadcast
(NTP mode 5) from one or more broadcast servers. (NTP mode 5) from one or more broadcast servers.
Broadcast clients may send unicast requests in order to measure
the network propagation delay between the server and client and
then continue operation in listen-only mode. However, broadcast
servers may choose not to respond to unicast requests, so unicast
clients should be prepared to abandon the measurement and assume a
default value for the delay.
Client requests are normally sent at intervals depending on the
frequency tolerance of the client clock and the required accuracy.
However, under no conditions should requests be sent at less than
one minute intervals. Further discussion on this point is in
Section 12.
A unicast client initializes the NTP message header, sends the A unicast client initializes the NTP message header, sends the
request to the server and strips the time of day from the Transmit request to the server and strips the time of day from the Transmit
Timestamp field of the reply. For this purpose, all of the NTP Timestamp field of the reply. For this purpose, all of the NTP
header fields shown in Section 3 are set to 0, except the Mode, VN header fields shown in Section 3 are set to 0, except the Mode, VN
and optional Transmit Timestamp fields. and optional Transmit Timestamp fields.
NTP and SNTP clients set the mode field to 3 (client) for unicast and NTP and SNTP clients set the mode field to 3 (client) for unicast
anycast requests. They set the VN field to any version number requests. They set the VN field to any version number supported by
supported by the server selected by configuration or discovery and the server selected by configuration or discovery and can
can interoperate with all previous version NTP and SNTP servers. interoperate with all previous version NTP and SNTP servers. Servers
Servers reply with the same version as the request, so the VN field reply with the same version as the request, so the VN field of the
of the request also specifies the VN field of the reply. An NTP request also specifies the VN field of the reply. An NTP client can
client can specify the earliest acceptable version on the expectation specify the earliest acceptable version on the expectation that any
that any server of that or later version will respond. NTPv4 servers server of that or later version will respond. NTPv4 servers are
are backwards compatible with NTPv3 as defined in RFC 1305, NTPv2 as backwards compatible with NTPv3 as defined in RFC 1305, NTPv2 as
defined in [9], and NTPv1 as defined in [10]. NTPv0 defined in [11] defined in [11], and NTPv1 as defined in [12]. NTPv0 defined in [13]
is not supported. is not supported.
In unicast mode, the Transmit Timestamp field in the request should In unicast mode, the Transmit Timestamp field in the request SHOULD
be set to the time of day according to the client clock in NTP be set to the time of day according to the client clock in NTP
timestamp format. This allows a simple calculation to determine the timestamp format. This allows for the determination of the
propagation delay between the server and client and to align the propagation delay between the server and client and to align the
system clock generally within a few tens of milliseconds relative to system clock relative to the server. In addition, this provides a
the server. In addition, this provides a simple method to verify simple method to verify that the server reply is in fact a legitimate
that the server reply is in fact a legitimate response to the response to the specific client request and avoid replays. Note that
specific client request and avoid replays. In broadcast mode, the in broadcast mode, the client cannot necessarily calculate the
client has no information to calculate the propagation delay or propagation delay or determine the validity of the server.
determine the validity of the server, unless one of the NTP
authentication schemes is used. The following table summarizes the
required NTP client operations in unicast, anycast and broadcast
modes. The recommended error checks are shown in the Reply and
Broadcast columns in the table. The message should be considered
valid only if all the fields shown contain values in the respective
ranges. Whether to believe the message if one or more of the fields
marked "ignore" contain invalid values is at the discretion of the
implementation.
There is some latitude on the part of most clients to forgive invalid There is some latitude on the part of most clients to forgive invalid
timestamps, such as might occur when first coming up or during timestamps, such as might occur when first coming up or during
periods when the reference source is inoperative. The most important periods when the reference source is inoperative. The most important
indicator of an unhealthy server is the Stratum field, in which a indicator of an unhealthy server is the Stratum field, in which a
value of 0 indicates an unsynchronized condition. When this value is value of 0 indicates an unsynchronized condition. When this value is
displayed, clients should discard the server message, regardless of displayed, clients should discard the server message, regardless of
the contents of other fields. the contents of other fields.
The following table summarizes the proper setting of these fields: Table 6 summarizes the required NTP client operations in unicast and
broadcast modes
+----------------+----------------+----------------+----------------+ +-------------------+---------------+-------------------+-----------+
| Field Name | Unicast | Unicast Reply | Broadcast | | Field Name | Unicast | Unicast Reply | Broadcast |
| | Request | | | | | Request | | |
+----------------+----------------+----------------+----------------+ +-------------------+---------------+-------------------+-----------+
| LI | 0 | 0-3 | 0-3 | | LI | 0 | 0-3 | 0-3 |
| VN | 1-4 | copied from | 1-4 | | VN | 1-4 | copied from | 1-4 |
| | | request | | | | | request | |
| Mode | 1 or 3 | 2 or 4 | 5 | | Mode | 1 or 3 | 2 or 4 | 5 |
| Stratum | 0 | 0-15 | 0-15 | | Stratum | 0 | 0-15 | 0-15 |
| Poll | 0 | ignore | ignore | | Poll | 0 | ignore | ignore |
| Precision | 0 | ignore | ignore | | Precision | 0 | ignore | ignore |
| Root Delay | 0 | ignore | ignore | | Root Delay | 0 | ignore | ignore |
| Root | 0 | ignore | ignore | | Root Dispersion | 0 | ignore | ignore |
| Dispersion | | | |
| Reference | 0 | ignore | ignore | | Reference | 0 | ignore | ignore |
| Identifier | | | | | Identifier | | | |
| Reference | 0 | ignore | ignore | | Reference | 0 | ignore | ignore |
| Timestamp | | | | | Timestamp | | | |
| Originate | 0 | (see text) | ignore | | Originate | 0 | (see text) | ignore |
| Timestamp | | | | | Timestamp | | | |
| Receive | 0 | (see text) | ignore | | Receive Timestamp | 0 | (see text) | ignore |
| Timestamp | | | |
| Transmit | (see text) | nonzero | nonzero | | Transmit | (see text) | nonzero | nonzero |
| Timestamp | | | | | Timestamp | | | |
| Authenticator | optional | optional | optional | | Authenticator | optional | optional | optional |
+----------------+----------------+----------------+----------------+ +-------------------+---------------+-------------------+-----------+
Table 6: NTP Client Message Field Population
8. NTP Symmetric Peer Operations 8. NTP Symmetric Peer Operations
NTP Symmetric Peer mode is intended for configurations where a set of NTP Symmetric Peer mode is intended for configurations where a set of
low-stratum peers operate as mutual backups for each other. Each low-stratum peers operate as mutual backups for each other. Each
peer normally operates with oner or more sources, such as a reference peer normally operates with one or more sources, such as a reference
clock, or a subset of primary or secondry servers known to be clock, or a subset of primary or secondry servers known to be
reliable or authentic. reliable or authentic.
Symmetric Peer mode is exclusive to the NTP protocol and is Symmetric Peer mode is exclusive to the NTP protocol and is
specifically excluded from SNTP operation. specifically excluded from SNTP operation. For the purposes of this
document, an NTP peer operates like a client.
9. NTPv4 Security 9. Dynamic Server Discovery
NTPv4 employs the Autokey security protocol, which works NTPv4 provides a mechanism, commonly known as "Manycast", for a
independently for each client, with tentative outcomes confirmed only client to dynamically discover the existance of one or more servers
after both succeed. Public keys and certificates are obtained and with no a-priori knowledge. Once servers are discovered, they are
verified relatively infrequently using X.509 certificates and then treated as any other unicast server.
certificate trails. Session keys are derived from public keys. Each
NTP message is individually authenticated using the session key and
the message digest (keyed MD5). A proventic trail is a sequence of
NTP servers each synchronized and cryptographically veritifed to the
next lower stratum server and ending on one or more trusted servers.
Proventic trails are constructed from each server to the trusted
servers at decreasing stratum levels. When server time and at least
one proventic trail are verified, the peer is admitted to the
population and used to synchronize the system clock.
9.1 Session Keys and Cookies A client employing server discovery is configured with MinServers,
the minimum number of desired servers and MaxServers, the maximum
number of desired servers. The discovery mechanism is a simple
expanding ring search, using IP multicast with increasing TTLs or Hop
Counts. The multicast address used MUST be scoped to the local site,
as defined by [14].
NTPv4 session keys have four 32-bit words, as shown in Figure 5. The client initiates the discovery process by sending an NTP message
to the configured multicast address (224.0.1.1 for IPv4 and a
multicast address ending :101 for IPv6 with proper scoping.) with an
IP TTL or Hop Count of 1. This message has all of the NTP header
fields set to 0, except the Mode, VN and optional Transmit Timestamp
fields. The Mode is set to 3. It then starts a retry timer
(Default: 64 seconds) and listens for unicast responses from servers.
The source address of any server responses are treated as newly
configured unicast servers, up to a limit of MaxServers. If the
number of discovered servers is less than MinServers when the retry
timer expires, an identical NTP message is sent with an increased
TTL/Hop Count, and the retry timer is restarted. This continues
until either MinServers servers have been discovered or a configured
maximum TTL/Hop Count is reached. If the configured maximum TTL/Hop
Count is reached, packets continue to be periodically sent at the
maximum TTL/Hop Count. If at some subsequent time, the number of
valid servers drops below MinServers, the process restarts at the
initial state.
0 1 2 3 A server configured to provide server discovery will listen on the
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 specified multicast address for discovery messages from clients. If
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the server is in scope of the current TTL and is itself synchronized
| Source Address | to a valid source it replies to the discovery message from the client
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ with an ordinary unicast server message as described in Section 6
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. NTPv4 Session Key Format 10. The Kiss-o'-Death Packet
The session key value is the 16-octet MD5 message digest of the According to the NTPv3 specification [1], if the Stratum field in the
session key. Key IDs have pseudo-random values and are used only NTP header is 1, indicating a primary server, the Reference
once. A special key ID value of zero is used as a NAK reply. In Identifier field contains an ASCII string identifying the particular
multicast mode, and in any message including an extension field, the reference clock type. However, in [1] nothing is said about the
cookie has a public value (zero). In client/server modes, the cookie Reference Identifier field if the Stratum field is 0, which is called
is a hash of the addresses and a private value. In symmetric modes, out as "unspecified". However, if the Stratum field is 0, the
the cookie is a random roll. In the event that both peers generate Reference Identifier field can be used to convey messages useful for
cookies, the agreed-upon cookie is the exclusive-OR of the two status reporting and access control. In NTPv4 and SNTPv4, packets of
values. this kind are called Kiss-o'-Death (KoD) packets and the ASCII
messages they convey are called kiss codes. The KoD packets got
their name because an early use was to tell clients to stop sending
packets that violate server access controls.
The server generates a cookie unique to the client and server The kiss codes can provide useful information for an intelligent
addresses and its own private value. It returns the cookie, client. These codes are encoded in four-character ASCII strings left
signature, and timestampe to the client in an extension field. The justified and zero filled. The strings are designed for character
cookie is transmitted from server to client encrypted by the client displays and log files. A list of the currently-defined kiss codes
public key. The server uses the cookie to validate requests and is given in Table 7.
construct replies. The client uses the cookie to validate the reply
and checks that the request key ID matches the reply key ID.
9.2 Session Key List Generation +------+------------------------------------------------------------+
| Code | Meaning |
+------+------------------------------------------------------------+
| ACST | The association belongs to a unicast server |
| 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 |
+------+------------------------------------------------------------+
The server rolls a random 32-bit seed as the initial key ID and Table 7: Currently-defined NTP Kiss Codes
selects the cookie. Messages with a zero cookie contain only public
values. The initial session key is constructed using the given
addressses, cookie and initial key ID. The session key value is
stored in the key cache. The next session key is constructed using
the first four octets of the session key value as the new key ID.
The server continues to generate the full list. The final index
number and last key ID are provided in an extension field with
signature and timestamp.
9.3 Sending Messages In general, an NTP client should stop sending to a particular server
if that server returns a reply with a Stratum field of 0, regardless
of kiss code, and an alternate server is available. If no alternate
server is available, the client SHOULD increase the poll interval as
performance permits.
The MAC consists of the MD5 message digest of the NTP header and 11. Security Considerations
extension fields using the session key ID and value stored in the key
cache. The server uses the session key ID list in reverse order and
discards each key value after use. An extension field containing the
last index number and key ID is included in the first packet
transmitted (last on the list). This extension field can be provided
upon request at any time. When all entries in the key list are used,
a new one is generated.
9.4 Receiving Messages NTPv4 provides an optional authentication field that utilizes the MD5
algorithm. MD5, as the case for SHA-1, is derived from MD4, which
has long been known to be weak. In 2004, techniques for efficiently
finding collisions in MD5 were announced. A summary of the weakness
of MD5 can be found in [15].
The intent is not to hide the message contents. Rather, the goal is In the case of NTP as specified herein, there is a vulnerability that
to verify its source and that it has not been modified in transit. NTP broadcast clients can be disrupted by misbehaving or hostile SNTP
The MAC message digest is compared with the computed digest of the or NTP broadcast servers elsewhere in the Internet. Access controls
NTP header and extension fields using the session key ID in the MAC and/or cryptographic authentication means should be provided for
and the key value computed from the addresses, key ID and cookie. If additional security in such cases.
the cookie is zero, the message contains public values. Anybody can
validate the message or make a valid message containing any values.
If the cookie has been determined by secret means, nobody except the
parties to the secret can validate a message or make a valid message.
9.5 Autokey Protocol Exchanges While not required in a conforming NTP client implementation, there
are a variety of recommended checks that an NTP client can perform
that are designed to avoid various types of abuse that might happen
as the result of server implementation errors or malicious attack.
These recommended checks are as follows:
There are five types of Autokey protocol exchanges: When the IP source and destination addresses are available for the
client request, they should match the interchanged addresses in
the server reply.
Parameter Exchange (ASSOC message): This message exchanges host When the UDP source and destination ports are available for the
names, agrees on digest/signature and identity schemes. This client request, they should match the interchanged ports in the
protocol exchange is unsigned. Optionally, host name/address can server reply.
be verified using reverse-DNS. An initial association request is
sent by the client, sending the host name and status word
0 1 2 3 The Originate Timestamp in the server reply should match the
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 Transmit Timestamp used in the client request.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest/Signature NID | Client | Ident | Host |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Status Word Format A client can check the Root Delay and Root Dispersion fields are
each greater than or equal to 0 and less than infinity, where
infinity is is on the order of 15-20 seconds. This check avoids
using a server whose synchronization source has expired for a very
long time.
If the server digest NID and ID scheme agree, the server responds 12. IANA Considerations
with an association response message, sending host name and status
word. The client, upon agreeing with digest NID and ID scheme,
then sends a certificate request. The server responds with an
X.509 certificate and signature. The certificate request/response
cycle repeats as needed. A primary (Stratum 1) certifcate is
explicitly trusted and self-signed. Secondary certificates are
signed by the next lower stratum server and validated with its
public key.
Certificate Exchange (CERT message): This exchange is used to UDP/TCP Port 123 was previously assigned by IANA for this protocol.
obtain and verify certificates on the trail to a trusted root The IANA has assigned the IPv4 multicast group address 224.0.1.1 and
certificate. Certificate exchanges follow the same process as the IPv6 multicast address ending :101 for NTP.
parameter exchanges.
Identity Exchange (IFF, GW, and MV messages): This exchange is This document identifies the set of defined 4-character (ASCII)
used to verify server identity using an agreed identity scheme Reference Identifier values. This document also defines the set of
(TC, IFF, GQ, MV). This exchange is a challenge-response scheme. defined Kiss Codes. This document also introduces NTP extension
The client initiates by sending a challenge request. The server fields allowing for the development of future extensions to the
then provides the challenge response. protocol, where a particular extension is to be identified by the
Field Type sub-field within the extension field.
Values Exchange (COOKIE and AUTO messages): This exchange is used IANA is requested to establish and maintain a registry for Reference
to obtain and verify the cookie, autokey values, and leapseconds Identifiers, Kiss codes, and Extension Field Types associated with
table, depending on the association mode (client-server, this protocol, populating this registry from the Reference
broadcast, symmetric). For cookie exchanges, the client sends its Identifiers given in Section 3.9 and Kiss Codes given in Section 11
public key to the server without signature when not synchronized. as the initial entries. The Extension Field Types registry will have
Symmetric active peers send its public key and signature to no initial entries. As future needs arise, new Reference
passive peer when synchronized. The server cookie is encrypted Identifiers, Kiss Codes, and Extension Field Types may be defined.
from the hash of source/destination addresses, zero key ID, and Following the policies outlined in [16], new values are to be defined
server private value. A symmetric passive cookie is a random by IETF Consensus.
value for every exchange. The server private value is refreshed
and protocol restarted once per day. For autokey exchanges, the
server generates a key list and signature is calculated to last
about one hour. A client sends requests to the server without
signature when not synchronized. The server replies with the last
index number and key ID on the list. Broadcast servers uses AUTO
response for the first message after regenerating the key and
ASSOC responses for all other messages.
Signature Exchange (SIGN message): This exchange requests the 13. Acknowledgements
server to sign and return a client certificate. The exchange is
valid only when the client has synchronized to a proventic source
and the server identity has been confirmed. This exchange is used
to authenticate clients to servers, with the server acting as de
facto certificate authority using an encrypted credential scheme.
The client sends a certificate to the server with or without
signature. The server extracts the requested data and signs that
data with the server private key. The client then verifies the
certificate and signature. Subsequently, the client supplies this
certificate rather than self-signed certificates, so clients can
verify with the server public key.
10. Dynamic Server Discovery This document has drawn material from RFC 4330, "Simple Network Time
Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI." As a result, the
authors would like to acknowledge D. Plonka of the University of
Wisconsin and J. Montgomery of Netgear, who were contributors. The
authors would also like to thank B. Haberman for providing rigorous
reviews of this document.
NTPv4 provides a mechanism, commonly known as "Manycast", for a 14. References
client to dynamically discover the existance of one or more servers
with no a-priori knowledge. Once servers are discovered, they are
then treated as any other unicast server.
A client employing server discovery is configured with MinServers, 14.1. Normative References
the minimum number of desired servers and MaxServers, the maximum
number of desired servers. The discovery mechanism is a simple
expanding ring search, using IP multicast with increasing TTLs or Hop
Counts. The multicast address used MUST be scoped to the local site,
as defined by [12].
The client initiates the discovery process by sending an NTP message [1] Mills, D., "Network Time Protocol (Version 3) Specification,
to the configured multicast address with an IP TTL or Hop Count of 1. Implementation", RFC 1305, March 1992.
This message has all of the NTP header fields set to 0, except the
Mode, VN and optional Transmit Timestamp fields. The Mode is set to
3. It then starts a retry timer (Default: 64 seconds) and listens
for unicast responses from servers. The source address of any server
responses are treated as newly configured unicast servers, up to a
limit of MaxServers. If the number of discovered servers is less
than MinServers when the retry timer expires, an identical NTP
message is sent with an increased TTL/Hop Count, and the retry timer
is restarted. This continues until either MinServers servers have
been discovered or a configured maximum TTL/Hop Count is reached. If
the configured maximum TTL/Hop Count is reached, packets continue to
be periodically sent at the maximum TTL/Hop Count. If at some
subsequent time, the number of valid servers drops below MinServers,
the process restarts at the initial state.
A server configured to provide server discovery will listen on the 14.2. Informative References
specified multicast address for discovery messages from clients. If
the server is in scope of the current TTL and is itself synchronized
to a valid source it replies to the discovery message from the client
with an ordinary unicast server message as described in Section 6
11. NTP Control Messages [2] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 4330, January 2006.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[4] Colella, R., Callon, R., Gardner, E., and Y. Rekhter,
"Guidelines for OSI NSAP Allocation in the Internet", RFC 1629,
May 1994.
[5] International Standards Organization, "International Standards
8602 - Information Processing Systems - OSI: Connectionless
Transport Protocol Specification.", NDSS , December 1986.
[6] Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless
transport services on top of UDP: Version 1", RFC 1240,
June 1991.
[7] Furniss, P., "Octet Sequences for Upper-Layer OSI to Support
Basic Communications Applications", RFC 1698, October 1994.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[10] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[11] Mills, D., "Network Time Protocol (version 2) specification and
implementation", STD 12, RFC 1119, September 1989.
[12] Mills, D., "Network Time Protocol (version 1) specification and
implementation", RFC 1059, July 1988.
[13] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.
[14] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.
[15] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm",
Proceedings of the 13th Annual ISOC Network and Distributed
System Security Symposium (NDSS) , February 2006.
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Appendix A. NTP Control Messages
In a comprehensive network-management environment, facilities are In a comprehensive network-management environment, facilities are
presumed available to perform routine NTP control and monitoring presumed available to perform routine NTP control and monitoring
functions, such as setting the leap-indicator bits at the primary functions, such as setting the leap-indicator bits at the primary
servers, adjusting the various system parameters and monitoring servers, adjusting the various system parameters and monitoring
regular operations. Ordinarily, these functions can be implemented regular operations. Ordinarily, these functions can be implemented
using a network-management protocol such as SNMP and suitable using a network-management protocol such as SNMP and suitable
extensions to the MIB database. However, in those cases where such extensions to the MIB database. However, in those cases where such
facilities are not available, these functions can be implemented facilities are not available, these functions can be implemented
using special NTP control messages described herein. These messages using special NTP control messages described herein. These messages
are intended for use only in systems where no other management are intended for use only in systems where no other management
facilities are available or appropriate, such as in dedicated- facilities are available or appropriate, such as in dedicated-
function bus peripherals. Support for these messages is not required function bus peripherals. Support for these messages is not required
in order to conform to this specification. in order to conform to this specification.
The NTP Control Message has the value 6 specified in the mode field The NTP Control Message has the value 6 specified in the mode field
of the first octet of the NTP header and is formatted as shown below. of the first octet of the NTP header and is formatted as shown in
The format of the data field is specific to each command or response; Section 10.1. The format of the data field is specific to each
however, in most cases the format is designed to be constructed and command or response; however, in most cases the format is designed to
viewed by humans and so is coded in free-form ASCII. This be constructed and viewed by humans and so is coded in free-form
facilitates the specification and implementation of simple management ASCII. This facilitates the specification and implementation of
tools in the absence of fully evolved network-management facilities. simple management tools in the absence of fully evolved network-
As in ordinary NTP messages, the authenticator field follows the data management facilities. As in ordinary NTP messages, the
field. If the authenticator is used the data field is zero-padded to authenticator field follows the data field. If the authenticator is
a 32-bit boundary, but the padding bits are not considered part of used the data field is zero-padded to a 32-bit boundary, but the
the data field and are not included in the field count. padding bits are not considered part of the data field and are not
included in the field count.
IP hosts are not required to reassemble datagrams larger than 576 IP hosts are not required to reassemble datagrams larger than 576
octets; however, some commands or responses may involve more data octets; however, some commands or responses may involve more data
than will fit into a single datagram. Accordingly, a simple than will fit into a single datagram. Accordingly, a simple
reassembly feature is included in which each octet of the message reassembly feature is included in which each octet of the message
data is numbered starting with zero. As each fragment is transmitted data is numbered starting with zero. As each fragment is transmitted
the number of its first octet is inserted in the offset field and the the number of its first octet is inserted in the offset field and the
number of octets is inserted in the count field. The more-data (M) number of octets is inserted in the count field. The more-data (M)
bit is set in all fragments except the last. bit is set in all fragments except the last.
skipping to change at page 26, line 5 skipping to change at page 28, line 38
in the status field indicate whether an exception has occurred since in the status field indicate whether an exception has occurred since
the last response and whether more than one exception has occurred. the last response and whether more than one exception has occurred.
Commands need not necessarily be sent by an NTP peer, so ordinary Commands need not necessarily be sent by an NTP peer, so ordinary
access-control procedures may not apply; however, the optional mask/ access-control procedures may not apply; however, the optional mask/
match mechanism suggested elsewhere in this document provides the match mechanism suggested elsewhere in this document provides the
capability to control access by mode number, so this could be used to capability to control access by mode number, so this could be used to
limit access for control messages (mode 6) to selected address limit access for control messages (mode 6) to selected address
ranges. ranges.
11.1 NTP Control Message Format A.1. NTP Control Message Format
The format of the NTP Control Message header, which immediately The format of the NTP Control Message header, which immediately
follows the UDP header, is shown in Figure X. Following is a follows the UDP header, is shown in Figure 7. Following is a
description of its fields. Bit positions marked as zero are reserved description of its fields. Bit positions marked as zero are reserved
and should always be transmitted as zero. and should always be transmitted as zero.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|00 |VN | 6 | REM | Op | Sequence | |00 |VN | 6 | REM | Op | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Association ID | | Status | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Count | | Offset | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
skipping to change at page 26, line 27 skipping to change at page 29, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Count | | Offset | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. Data (468 Octets Max) . . Data (468 Octets Max) .
. . . .
| | Padding (zeros) | | | Padding (zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator (optional)(96) | | Authenticator (optional)(96) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Control Message Format
Figure 7: NTP Control Message Format
Version Number (VN): This is a three-bit integer indicating the NTP Version Number (VN): This is a three-bit integer indicating the NTP
version number, currently four (4) version number, currently four (4)
Mode: This is a three-bit integer indicating the mode. It must have Mode: This is a three-bit integer indicating the mode. It must have
the value 6, indicating an NTP control message. the value 6, indicating an NTP control message.
Response Bit (R): Set to zero for commands, one for responses. Response Bit (R): Set to zero for commands, one for responses.
Error Bit (E): Set to zero for normal response, one for error Error Bit (E): Set to zero for normal response, one for error
response. response.
More Bit (M): Set to zero for last fragment, one for all others. More Bit (M): Set to zero for last fragment, one for all others.
Operation Code (Op): This is a five-bit integer specifying the Operation Code (Op): This is a five-bit integer specifying the
command function. Values currently defined include the following: command function. Values currently defined are given in Table 8.
+-------+----------------------------------------+ +-------+----------------------------------------+
| Value | Meaning | | Value | Meaning |
+-------+----------------------------------------+ +-------+----------------------------------------+
| 0 | reserved | | 0 | reserved |
| 1 | read status command/response | | 1 | read status command/response |
| 2 | read variables command/response | | 2 | read variables command/response |
| 3 | write variables command/response | | 3 | write variables command/response |
| 4 | read clock variables command/response | | 4 | read clock variables command/response |
| 5 | write clock variables command/response | | 5 | write clock variables command/response |
| 6 | set trap address/port command/response | | 6 | set trap address/port command/response |
| 7 | trap response | | 7 | trap response |
| 8-31 | reserved | | 8-31 | reserved |
+-------+----------------------------------------+ +-------+----------------------------------------+
Table 8: Currently-defined Operation Codes
Sequence: This is a 16-bit integer indicating the sequence number of Sequence: This is a 16-bit integer indicating the sequence number of
the command or response. the command or response.
Status: This is a 16-bit code indicating the current status of the Status: This is a 16-bit code indicating the current status of the
system, peer or clock, with values coded as described in following system, peer or clock, with values coded as described in following
sections. sections.
Association ID: This is a 16-bit integer identifying a valid Association ID: This is a 16-bit integer identifying a valid
association. association.
skipping to change at page 27, line 41 skipping to change at page 30, line 43
Count: This is a 16-bit integer indicating the length of the data Count: This is a 16-bit integer indicating the length of the data
field, in octets. field, in octets.
Data: This contains the message data for the command or response. Data: This contains the message data for the command or response.
The maximum number of data octets is 468. The maximum number of data octets is 468.
Authenticator (optional): When the NTP authentication mechanism is Authenticator (optional): When the NTP authentication mechanism is
implemented, this contains the authenticator information. implemented, this contains the authenticator information.
11.2 Status Words A.2. Status Words
Status words indicate the present status of the system, associations Status words indicate the present status of the system, associations
and clock. They are designed to be interpreted by network-monitoring and clock. They are designed to be interpreted by network-monitoring
programs and are in one of four 16-bit formats shown in Figure programs and are in one of four 16-bit formats described in this
6<$&fig6> and described in this section. System and peer status section. System and peer status words are associated with responses
words are associated with responses for all commands except the read for all commands except the read clock variables, write clock
clock variables, write clock variables and set trap address/port variables and set trap address/port commands. The association
commands. The association identifier zero specifies the system identifier zero specifies the system status word, while a nonzero
status word, while a nonzero identifier specifies a particular peer identifier specifies a particular peer association. The status word
association. The status word returned in response to read clock returned in response to read clock variables and write clock
variables and write clock variables commands indicates the state of variables commands indicates the state of the clock hardware and
the clock hardware and decoding software. A special error status decoding software. A special error status word is used to report
word is used to report malformed command fields or invalid values. malformed command fields or invalid values.
11.2.1 System Status Word A.2.1. System Status Word
The system status word appears in the status field of the response to The system status word appears in the status field of the response to
a read status or read variables command with a zero association a read status or read variables command with a zero association
identifier. The format of the system status word is as follows: identifier. The format of the system status word is given in
Figure 8.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| LI | Clock Source | Count | Code | | LI | Clock Source | Count | Code |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
System Status Word
Figure 8: System Status Word Format
Leap Indicator (LI): This is a two-bit code warning of an impending Leap Indicator (LI): This is a two-bit code warning of an impending
leap second to be inserted/deleted in the last minute of the current leap second to be inserted/deleted in the last minute of the current
day, with bit 0 and bit 1, respectively, coded as follows: day, with bit 0 and bit 1, respectively, coded as shown in Table 9.
+-------+------------------------------------------+ +-------+------------------------------------------+
| Value | Meaning | | Value | Meaning |
+-------+------------------------------------------+ +-------+------------------------------------------+
| 00 | no warning | | 00 | no warning |
| 01 | last minute has 61 seconds | | 01 | last minute has 61 seconds |
| 10 | last minute has 59 seconds | | 10 | last minute has 59 seconds |
| 11 | alarm condition (clock not synchronized) | | 11 | alarm condition (clock not synchronized) |
+-------+------------------------------------------+ +-------+------------------------------------------+
Table 9: Leap Indicator Field
Clock Source: This is a six-bit integer indicating the current Clock Source: This is a six-bit integer indicating the current
synchronization source, with values coded as follows: synchronization source, with values coded as shown in Table 10.
+-------+---------------------------------------------------------+ +-------+---------------------------------------------------------+
| Value | Meaning | | Value | Meaning |
+-------+---------------------------------------------------------+ +-------+---------------------------------------------------------+
| 0 | unspecified or unknown | | 0 | unspecified or unknown |
| 1 | Calibrated atomic clock (e.g.,, HP 5061) | | 1 | Calibrated atomic clock (e.g.,, HP 5061) |
| 2 | VLF (band 4) or LF (band 5) radio (e.g.,, OMEGA,, WWVB) | | 2 | VLF (band 4) or LF (band 5) radio (e.g.,, OMEGA,, WWVB) |
| 3 | HF (band 7) radio (e.g.,, CHU,, MSF,, WWV/H) | | 3 | HF (band 7) radio (e.g.,, CHU,, MSF,, WWV/H) |
| 4 | UHF (band 9) satellite (e.g.,, GOES,, GPS) | | 4 | UHF (band 9) satellite (e.g.,, GOES,, GPS) |
| 5 | local net (e.g.,, DCN,, TSP,, DTS) | | 5 | local net (e.g.,, DCN,, TSP,, DTS) |
| 6 | UDP/NTP | | 6 | UDP/NTP |
| 7 | UDP/TIME | | 7 | UDP/TIME |
| 8 | eyeball-and-wristwatch | | 8 | wall time |
| 9 | telephone modem (e.g. NIST) | | 9 | telephone modem (e.g. NIST) |
| 10-63 | reserved | | 10-31 | reserved |
| 32 | PPS signal |
| 33-63 | reserved |
+-------+---------------------------------------------------------+ +-------+---------------------------------------------------------+
Table 10: Clock Source Field Values
System Event Counter: This is a four-bit integer indicating the System Event Counter: This is a four-bit integer indicating the
number of system exception events occurring since the last time the number of system exception events occurring since the last time the
system status word was returned in a response or included in a trap system status word was returned in a response or included in a trap
message. The counter is cleared when returned in the status field of message. The counter is cleared when returned in the status field of
a response and freezes when it reaches the value 15. a response and freezes when it reaches the value 15.
System Event Code: This is a four-bit integer identifying the latest System Event Code: This is a four-bit integer identifying the latest
system exception event, with new values overwriting previous values, system exception event, with new values overwriting previous values,
and coded as follows: and coded as shown in Table 11.
+---------------------------------+---------------------------------+ +-------+-----------------------------------------------------------+
| Value | Meaning | | Value | Meaning |
+---------------------------------+---------------------------------+ +-------+-----------------------------------------------------------+
| 0 | unspecified | | 0 | unspecified |
| 1 | system restart | | 1 | system restart |
| 2 | system or hardware fault | | 2 | system or hardware fault |
| 3 | system new status word (leap | | 3 | system new status word (leap bits or synchronization |
| | bits or synchronization change) | | | change) |
| 4 | system new synchronization | | 4 | system new synchronization source or stratum (sys.peer or |
| | source or stratum (sys.peer or | | | sys.stratum) change |
| | sys.stratum change | | 5 | system clock reset (offset correction exceeds CLOCK.MAX) |
| 5 | system clock reset (offset |
| | correction exceeds CLOCK.MAX) |
| 6 | system invalid time or date | | 6 | system invalid time or date |
| | (see NTP specification) | | 7 | system clock exception (see system clock status word) |
| 7 | system clock exception (see |
| | system clock status word) |
| 8-15 | reserved | | 8-15 | reserved |
+---------------------------------+---------------------------------+ +-------+-----------------------------------------------------------+
11.2.2 Peer Status Word Table 11: System Event Code Values
A.2.2. Peer Status Word
A peer status word is returned in the status field of a response to a A peer status word is returned in the status field of a response to a
read status, read variables or write variables command and appears read status, read variables or write variables command and appears
also in the list of association identifiers and status words returned also in the list of association identifiers and status words returned
by a read status command with a zero association identifier. The by a read status command with a zero association identifier. The
format of a peer status word is as follows: format of a peer status word is shown in Figure 9.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Peer Status | Sel | Count | Code | | Peer Status | Sel | Count | Code |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Peer Status Word Peer Status Word
Figure 9: Peer Status Word Format
Peer Status: This is a five-bit code indicating the status of the Peer Status: This is a five-bit code indicating the status of the
peer determined by the packet procedure, with bits assigned as peer determined by the packet procedure, with bits assigned as shown
follows: in Table 12.
+-------+------------------------------------------+ +-------+------------------------------------------+
| Value | Meaning | | Value | Meaning |
+-------+------------------------------------------+ +-------+------------------------------------------+
| 0 | configured (peer.config) | | 0 | configured (peer.config) |
| 1 | authentication enabled (peer.authenable) | | 1 | authentication enabled (peer.authenable) |
| 2 | authentication okay (peer.authentic) | | 2 | authentication okay (peer.authentic) |
| 3 | reachability okay (peer.reach) | | 3 | reachability okay (peer.reach) |
| 4 | reserved | | 4 | reserved |
+-------+------------------------------------------+ +-------+------------------------------------------+
Table 12: Peer Status Values
Peer Selection (Sel): This is a three-bit integer indicating the Peer Selection (Sel): This is a three-bit integer indicating the
status of the peer determined by the clock-selection procedure, with status of the peer determined by the clock-selection procedure, with
values coded as follows: values coded as shown in Table 13.
+---------------------------------+---------------------------------+ +-------+-----------------------------------------------------------+
| Value | Meaning | | Value | Meaning |
+---------------------------------+---------------------------------+ +-------+-----------------------------------------------------------+
| 0 | rejected | | 0 | rejected |
| 1 | passed sanity checks | | 1 | passed sanity checks |
| 2 | passed correctness checks | | 2 | passed correctness checks |
| 3 | passed candidate checks (if | | 3 | passed candidate checks (if limit check implemented) |
| | limit check implemented) |
| 4 | passed outlyer checks | | 4 | passed outlyer checks |
| 5 | current synchronization source; | | 5 | current synchronization source; max distance exceeded (if |
| | max distance exceeded (if limit | | | limit check implemented) |
| | check implemented) | | 6 | current synchronization source; max distance okay |
| 6 | current synchronization source; |
| | max distance okay |
| 7 | reserved | | 7 | reserved |
+---------------------------------+---------------------------------+ +-------+-----------------------------------------------------------+
Table 13: Peer Selection Field Values
Peer Event Counter: This is a four-bit integer indicating the number Peer Event Counter: This is a four-bit integer indicating the number
of peer exception events that occurred since the last time the peer of peer exception events that occurred since the last time the peer
status word was returned in a response or included in a trap message. status word was returned in a response or included in a trap message.
The counter is cleared when returned in the status field of a The counter is cleared when returned in the status field of a
response and freezes when it reaches the value 15. response and freezes when it reaches the value 15.
Peer Event Code: This is a four-bit integer identifying the latest Peer Event Code: This is a four-bit integer identifying the latest
peer exception event, with new values overwriting previous values, peer exception event, with new values overwriting previous values,
and coded as follows: and coded as shown in Table 14.
+---------------------------------+---------------------------------+ +-------+-----------------------------------------------------------+
| Value | Meaning | | Value | Meaning |
+---------------------------------+---------------------------------+ +-------+-----------------------------------------------------------+
| 0 | unspecified | | 0 | unspecified |
| 1 | peer IP error | | 1 | peer IP error |
| 2 | peer authentication failure | | 2 | peer authentication failure (peer.authentic bit was one |
| | (peer.authentic bit was one now | | | now zero) |
| | zero) | | 3 | peer unreachable (peer.reach was nonzero now zero) |
| 3 | peer unreachable (peer.reach | | 4 | peer reachable (peer.reach was zero now nonzero) |
| | was nonzero now zero) | | 5 | peer clock exception (see peer clock status word) |
| 4 | peer reachable (peer.reach was |
| | zero now nonzero) |
| 5 | peer clock exception (see peer |
| | clock status word) |
| 6-15 | reserved | | 6-15 | reserved |
+---------------------------------+---------------------------------+ +-------+-----------------------------------------------------------+
11.2.3 Clock Status Word Table 14: Peer Event Codes
A.2.3. Clock Status Word
There are two ways a reference clock can be attached to a NTP service There are two ways a reference clock can be attached to a NTP service
host, as an dedicated device managed by the operating system and as a host, as an dedicated device managed by the operating system and as a
synthetic peer managed by NTP. As in the read status command, the synthetic peer managed by NTP. As in the read status command, the
association identifier is used to identify which one, zero for the association identifier is used to identify which one, zero for the
system clock and nonzero for a peer clock. Only one system clock is system clock and nonzero for a peer clock. Only one system clock is
supported by the protocol, although many peer clocks can be supported by the protocol, although many peer clocks can be
supported. A system or peer clock status word appears in the status supported. A system or peer clock status word appears in the status
field of the response to a read clock variables or write clock field of the response to a read clock variables or write clock
variables command. This word can be considered an extension of the variables command. This word can be considered an extension of the
system status word or the peer status word as appropriate. The system status word or the peer status word as appropriate. The
format of the clock status word is as follows: format of the clock status word is shown in Figure 10.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Clock Status | Code | | Clock Status | Code |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Clock Status Word
Figure 10: Clock Status Word Format
Clock Status: This is an eight-bit integer indicating the current Clock Status: This is an eight-bit integer indicating the current
clock status, with values coded as follows: clock status, with values coded as shown in Table 15.
+-------+---------------------------------+ +-------+----------------------------+
| Value | Meaning | | Value | Meaning |
+-------+---------------------------------+ +-------+----------------------------+
| 0 | clock operating within nominals | | 0 | clock nominally operating |
| 1 | reply timeout | | 1 | reply timeout |
| 2 | bad reply format | | 2 | bad reply format |
| 3 | hardware or software fault | | 3 | hardware or software fault |
| 4 | propagation failure | | 4 | propagation failure |
| 5 | bad date format or value | | 5 | bad date format or value |
| 6 | bad time format or value | | 6 | bad time format or value |
| 7-255 | reserved | | 7-255 | reserved |
+-------+---------------------------------+ +-------+----------------------------+
Table 15: Clock Status Values
Clock Event Code: This is an eight-bit integer identifying the latest Clock Event Code: This is an eight-bit integer identifying the latest
clock exception event, with new values overwriting previous values. clock exception event, with new values overwriting previous values.
When a change to any nonzero value occurs in the radio status field, When a change to any nonzero value occurs in the radio status field,
the radio status field is copied to the clock event code field and a the radio status field is copied to the clock event code field and a
system or peer clock exception event is declared as appropriate. system or peer clock exception event is declared as appropriate.
11.2.4 Error Status Word A.2.4. Error Status Word
An error status word is returned in the status field of an error An error status word is returned in the status field of an error
response as the result of invalid message format or contents. Its response as the result of invalid message format or contents. Its
presence is indicated when the E (error) bit is set along with the presence is indicated when the E (error) bit is set along with the
response (R) bit in the response. It consists of an eight-bit response (R) bit in the response. It consists of an eight-bit
integer coded as follows: integer coded as shown in Figure 11.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Error Code | Reserved | | Error Code | Reserved |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Error Status Word
Figure 11: Error Status Word Format
Currently-defined error codes are given in Table 16.
+-------+----------------------------------+ +-------+----------------------------------+
| Value | Meaning | | Value | Meaning |
+-------+----------------------------------+ +-------+----------------------------------+
| 0 | unspecified | | 0 | unspecified |
| 1 | authentication failure | | 1 | authentication failure |
| 2 | invalid message length or format | | 2 | invalid message length or format |
| 3 | invalid opcode | | 3 | invalid opcode |
| 4 | unknown association identifier | | 4 | unknown association identifier |
| 5 | unknown variable name | | 5 | unknown variable name |
| 6 | invalid variable value | | 6 | invalid variable value |
| 7 | administratively prohibited | | 7 | administratively prohibited |
| 8-255 | reserved | | 8-255 | reserved |
+-------+----------------------------------+ +-------+----------------------------------+
11.3 Commands Table 16: Error Code Values
Commands consist of the header and optional data field shown in A.3. Commands
Figure 6. When present, the data field contains a list of
identifiers or assignments in the form Commands consist of the header and optional data field of the Status
Word. When present, the data field contains a list of identifiers or
assignments in the form
<<identifier>>[=<<value>>],<<identifier>>[=<<value>>],... <<identifier>>[=<<value>>],<<identifier>>[=<<value>>],...
where <<identifier>> is the ASCII name of a system or peer variable where <<identifier>> is the ASCII name of a system or peer variable
specified in Table 2 or Table 3 and <<value>> is expressed as a specified in Table 2 or Table 3 of [1] and <<value>> is expressed as
decimal, hexadecimal or string constant in the syntax of the C a decimal, hexadecimal or string constant in the syntax of the C
programming language. Where no ambiguity exists, the <169>sys.<170> programming language. Where no ambiguity exists, the <169>sys.<170>
or <169>peer.<170> prefixes shown in Table 2 or Table 4 can be or <169>peer.<170> prefixes shown in Table 2 or Table 4 of [1] can be
suppressed. Whitespace (ASCII nonprinting format effectors) can be suppressed. Whitespace (ASCII nonprinting format effectors) can be
added to improve readability for simple monitoring programs that do added to improve readability for simple monitoring programs that do
not reformat the data field. Internet addresses are represented as not reformat the data field. Internet addresses are represented as
four octets in the form [n.n.n.n], where n is in decimal notation and four octets in the form [n.n.n.n], where n is in decimal notation and
the brackets are optional. Timestamps, including reference, the brackets are optional. Timestamps, including reference,
originate, receive and transmit values, as well as the logical clock, originate, receive and transmit values, as well as the logical clock,
are represented in units of seconds and fractions, preferably in are represented in units of seconds and fractions, preferably in
hexadecimal notation, while delay, offset, dispersion and distance hexadecimal notation, while delay, offset, dispersion and distance
values are represented in units of milliseconds and fractions, values are represented in units of milliseconds and fractions,
preferably in decimal notation.All other values are represented preferably in decimal notation.All other values are represented
as-is, preferably in decimal notation. as-is, preferably in decimal notation.
Implementations may define variables other than those listed in Table Implementations may define variables other than those listed in Table
2 or Table 3. Called extramural variables, these are distinguished 2 or Table 3 of [1]. Called extramural variables, these are
by the inclusion of some character type other than alphanumeric or distinguished by the inclusion of some character type other than
<169>.<170> in the name. For those commands that return a list of alphanumeric or <169>.<170> in the name. For those commands that
assignments in the response data field, if the command data field is return a list of assignments in the response data field, if the
empty, it is expected that all available variables defined in Table 3 command data field is empty, it is expected that all available
or Table 4 of the NTP specification will be included in the response. variables defined in Table 3 or Table 4 of [1] will be included in
For the read commands, if the command data field is nonempty, an the response. For the read commands, if the command data field is
implementation may choose to process this field to individually nonempty, an implementation may choose to process this field to
select which variables are to be returned. individually select which variables are to be returned.
Commands are interpreted as follows: Commands are interpreted as follows:
Read Status (1): The command data field is empty or contains a list Read Status (1): The command data field is empty or contains a list
of identifiers separated by commas. The command operates in two ways of identifiers separated by commas. The command operates in two ways
depending on the value of the association identifier. If this depending on the value of the association identifier. If this
identifier is nonzero, the response includes the peer identifier and identifier is nonzero, the response includes the peer identifier and
status word. Optionally, the response data field may contain other status word. Optionally, the response data field may contain other
information, such as described in the Read Variables command. If the information, such as described in the Read Variables command. If the
association identifier is zero, the response includes the system association identifier is zero, the response includes the system
skipping to change at page 35, line 10 skipping to change at page 39, line 5
exception event occurs. The opcode field is 7 and the R bit is set. exception event occurs. The opcode field is 7 and the R bit is set.
The trap counter is incremented by one for each trap sent and the The trap counter is incremented by one for each trap sent and the
sequence field set to that value. The trap message is sent using the sequence field set to that value. The trap message is sent using the
IP address and port fields established by the set trap address/port IP address and port fields established by the set trap address/port
command. If a system trap the association identifier field is set to command. If a system trap the association identifier field is set to
zero and the status field contains the system status word. If a peer zero and the status field contains the system status word. If a peer
trap the association identifier field is set to that peer and the trap the association identifier field is set to that peer and the
status field contains the peer status word. Optional ASCII-coded status field contains the peer status word. Optional ASCII-coded
information can be included in the data field. information can be included in the data field.
12. The Kiss-o'-Death Packet
In the interest of self-preservation, it is important that NTP
servers have a mechanism to supress or otherwise influence the amount
of queries performed by NTP clients.
According to the NTPv3 specification RFC 1305, if the Stratum field
in the NTP header is 1, indicating a primary server, the Reference
Identifier field contains an ASCII string identifying the particular
reference clock type. However, in RFC 1305 nothing is said about the
Reference Identifier field if the Stratum field is 0, which is called
out as "unspecified". However, if the Stratum field is 0, the
Reference Identifier field can be used to convey messages useful for
status reporting and access control. In NTPv4 and SNTPv4, packets of
this kind are called Kiss-o'-Death (KoD) packets and the ASCII
messages they convey are called kiss codes. The KoD packets got
their name because an early use was to tell clients to stop sending
packets that violate server access controls.
The kiss codes can provide useful information for an intelligent
client. These codes are encoded in four-character ASCII strings left
justified and zero filled. The strings are designed for character
displays and log files. A list of the currently-defined kiss codes
is in the following table.
+---------------------------------+---------------------------------+
| Code | Meaning |
+---------------------------------+---------------------------------+
| ACST | The association belongs to an |
| | anycast server |
| 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 | Somebody is tinkering with the |
| | association from a remote host |
| | running ntpdc. Not to worry |
| | unless some rascal has stolen |
| | your keys |
| STEP | A step change in system time |
| | has occurred, but the |
| | association has not yet |
| | resynchronized |
+---------------------------------+---------------------------------+
In general, an NTP client should stop sending to a particular server
if that server returns a reply with a Stratum field of 0, regardless
of kiss code, and an alternate server is available. If no alternate
server is available, the client should retransmit using an
exponential-backoff algorithm described in Section 15.
13. Security Considerations
In the case of NTP as specified herein, there is a very real
vulnerability that NTP broadcast clients can be disrupted by
misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the
Internet. It is strongly recommended that access controls and/or
cryptographic authentication means be provided for additional
security in such cases.
While not required in a conforming NTP client implementation, there
are a variety of recommended checks that an NTP client can perform
that are designed to avoid various types of abuse that might happen
as the result of server implementation errors or malicious attack.
These recommended checks are as follows:
When the IP source and destination addresses are available for the
client request, they should match the interchanged addresses in
the server reply.
When the UDP source and destination ports are available for the
client request, they should match the interchanged ports in the
server reply.
The Originate Timestamp in the server reply should match the
Transmit Timestamp used in the client request.
The server reply should be discarded if any of the LI, Stratum, or
Transmit Timestamp fields are 0 or the Mode field is not 4
(unicast) or 5 (broadcast).
A truly paranoid client can check the Root Delay and Root
Dispersion fields are each greater than or equal to 0 and less
than infinity, where infinity is currently a cozy number like 16
seconds. This check avoids using a server whose synchronization
source has expired for a very long time.
14. IANA Considerations
15. Other Considerations
NTP and SNTP clients can consume considerable network and server
resources if not "good network citizens." There are now consumer
Internet commodity devices numbering in the millions that are
potential customers of public and private NTP and SNTP servers.
Recent experience strongly suggests that device designers pay
particular attention to minimizing resource impacts, especially if
large numbers of these devices are deployed. The most important
design consideration is the interval between client requests, called
the poll interval. It is extremely important that the design use the
maximum poll interval consistent with acceptable accuracy.
A client MUST NOT use a poll interval less than TBD minutes.
A client SHOULD increase the poll interval using exponential
backoff as performance permits and especially if the server does
not respond within a reasonable time.
A client SHOULD use local servers whenever available to avoid
unnecessary traffic on backbone networks.
A client MUST allow the operator to configure the primary and/or
alternate server names or addresses in addition to or in place of
a firmware default IP address.
If a firmware default server IP address is provided, it MUST be a
server operated by the manufacturer or seller of the device or
another server, but only with the operator's permission.
A client SHOULD use the Domain Name System (DNS) to resolve the
server IP addresses, so the operator can do effective load
balancing among a server clique and change IP address binding to
canonical names.
A client SHOULD re-resolve the server IP address on a periodic
intervals, but not less than the time-to-live field in the DNS
response.
A client SHOULD support the NTP access-refusal mechanism, so that
a server kiss-o'-death reply in response to a client request
causes the client to cease sending requests to that server and to
switch to an alternate, if available.
If the firmware or documentation includes specific server names, the
names should be those the manufacturer or seller operates as a
customer convenience or those for which specific permission has been
obtained from the operator. A DNS request for a generic server name
such as ntp.mytimeserver.com results should result in a random
selection of server IP addresses available for that purpose. Each
time a DNS request is received, a new randomized list is returned.
The client ordinarily uses the first address on the list.
When selecting candidate SNTP or NTP servers, it is imperative to
respect the server operator's conditions of access. Lists of
public servers and their conditions of access are available at
www.ntp.org. A semi-automatic server discovery scheme using DNS
is described at that site. Some ISPs operate public servers,
although finding them via their helpdesks can be difficult.
A well behaved client operates as follows (note that steps 2 - 4
comprise a synchronization loop):
Consider the specified frequency tolerance of the system clock
oscillator. Define the required accuracy of the system clock,
then calculate the maximum timeout. For instance, if the
frequency tolerance is 200 parts-per-million (PPM) and the
required accuracy is one minute, the maximum timeout is about 3.5
days. Use the longest maximum timeout possible given the system
constraints to minimize time server aggregate load, but never less
than 15 minutes.
When first coming up or after reset, randomize the timeout from
one to five minutes. This is to minimize shock when 3000 PCs are
rebooted at the same time power is restored after a blackout.
Assume at this time the IP address is unknown and the system clock
is unsynchronized. Otherwise use the timeout value as calculated
in previous loop steps. Note that it may be necessary to refrain
from implementing the aforementioned random delay for some classes
of ICSA certification.
When the timer reaches zero, if the IP address is not known, send
a DNS query packet; otherwise send a NTP request packet to that
address. If no reply packet has been heard since the last
timeout, double the timeout, but not greater than the maximum
timeout. If primary and secondary time servers have been
configured, alternate queries between the primary and secondary
servers when no successful response has been received.
If a DNS reply packet is received, save the IP address and
continue in step 2. If a KoD packet is received remove that time
server from the list, activate the secondary time server and
continue in step 2. If a received packet fails the sanity checks,
drop that packet and also continue in step 2. If a valid NTP
packet is received, update the system clock, set the timeout to
the maximum, and continue to step 2.
16. Acknowledgements
This document has drawn significant material from the document
draft-mills-sntp-v4-00.txt. As a result, the authors would like to
acknowledge D. Plonka of the University of Wisconsin and J.
Montgomery of Netgear, who were significant contributors to that
draft.
17. References
17.1 Normative References
[1] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[2] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 2030, October 1996.
17.2 Informative References
[3] International Standards Organization, "International Standards
8602 - Information Processing Systems - OSI: Connectionless
Transport Protocol Specification.", ISO 8602, December 1986.
[4] Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless
transport services on top of UDP: Version 1", RFC 1240,
June 1991.
[5] Furniss, P., "Octet Sequences for Upper-Layer OSI to Support
Basic Communications Applications", RFC 1698, October 1994.
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[7] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[9] Mills, D., "Network Time Protocol (version 2) specification and
implementation", STD 12, RFC 1119, September 1989.
[10] Mills, D., "Network Time Protocol (version 1) specification and
implementation", RFC 1059, July 1988.
[11] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.
[12] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.
[13] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[14] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
Authors' Addresses Authors' Addresses
Jack Burbank (editor) Jack Burbank (editor)
Johns Hopkins University Applied Physics Lab The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road 11100 Johns Hopkins Road
Laurel, MD 20723-6099 Laurel, MD 20723-6099
US US
Phone: +1 443 778 7127 Phone: +1 443 778 7127
Email: jack.burbank@jhuapl.edu Email: jack.burbank@jhuapl.edu
Jim Martin (editor) Jim Martin (editor)
Netzwert AG Netzwert AG
An den Treptowers 1 An den Treptowers 1
Berlin 12435 Berlin 12435
Germany Germany
Phone: +49.30/5 900 80-1180 Phone: +49.30/5 900 80-1180
Email: jim@netzwert.ag Email: jim@netzwert.ag
Dr. David L. Mills Dr. David L. Mills
skipping to change at page 42, line 41 skipping to change at page 40, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 197 change blocks. 
896 lines changed or deleted 808 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/