draft-ietf-ntp-ntpv4-proto-00.txt   draft-ietf-ntp-ntpv4-proto-01.txt 
Network Time Protocol Working J. Burbank (Editor) NTP WG J. Burbank, Ed.
Group JHU/APL Internet-Draft JHU APL
Internet-Draft J. Martin (co-Editor) Expires: April 26, 2006 J. Martin, Ed.
Expires: January 9, 2006 Netzwert AG Netzwert AG
July, 2005 D. Mills
U. Del.
October 23, 2005
The Network Time Protocol Version 4 Protocol Specification The Network Time Protocol Version 4 Protocol Specification
<draft-ietf-ntp-ntpv4-proto-00> draft-ietf-ntp-ntpv4-proto-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3978. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she becomes 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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 document is a submission of the IETF NTP WG. Comments should be This Internet-Draft will expire on April 26, 2006.
directed to the NTP WG mailing list, ntpwg@lists.ntp.isc.org.
This Internet-Draft will expire on January 9, 2006. Copyright Notice
Copyright (C) The Internet Society (2005).
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 computer clocks in the Internet. This memorandum describes Version 4
Version 4 of the NTP (NTPv4), introducing several changes from of the NTP (NTPv4), introducing several changes from Version 3 of NTP
Version 3 of NTP (NTPv3) described in RFC 1305, including the (NTPv3) described in RFC 1305, including the introduction of a
introduction of a modified protocol header to accomodate Internet modified protocol header to accomodate Internet Protocol Version 6.
Protocol Version 6. NTPv4 also includes optional extensions to the
NTPv3 protocol,including an anycast mode and an authentication scheme
designed specifically for multicast and anycast modes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NTPv4 Protocol Operation . . . . . . . . . . . . . . . . . . . 4
3. NTPv4 Timestamp Format . . . . . . . . . . . . . . . . . . . . 6
4. NTPv4 Message Formats . . . . . . . . . . . . . . . . . . . . 7
5. NTPv4 Client Operations . . . . . . . . . . . . . . . . . . . 13
6. NTPv4 Server Operations . . . . . . . . . . . . . . . . . . . 15
7. NTPv4 Security . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1 Session Keys and Cookies . . . . . . . . . . . . . . . . . 19
7.2 Session Key List Generation . . . . . . . . . . . . . . . 20
7.3 Sending Messages . . . . . . . . . . . . . . . . . . . . . 20
7.4 Receiving Messages . . . . . . . . . . . . . . . . . . . . 20
7.5 Autokey Protocol Exchanges . . . . . . . . . . . . . . . . 20
8. Operation and Management Issues . . . . . . . . . . . . . . . 22
9. Kiss o' Death Message . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. Other Considerations . . . . . . . . . . . . . . . . . . . . . 25
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 NTPv4 also includes optional extensions to the NTPv3
protocol,including a dynamic server discovery mechanism and an
authentication scheme designed specifically for multicast and
dynamically discovered servers.
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Table of Contents
14.1 Normative References . . . . . . . . . . . . . . . . . . 27
14.2 Informative References . . . . . . . . . . . . . . . . . 27
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . 29 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. NTP Timestamp . . . . . . . . . . . . . . . . . . . . . . . 5
3. NTP Message Formats . . . . . . . . . . . . . . . . . . . . 7
3.1 Leap Indicator (LI) . . . . . . . . . . . . . . . . . . . 8
3.2 Version (VN) . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Stratum (Strat) . . . . . . . . . . . . . . . . . . . . . 10
3.5 Poll Interval (Poll) . . . . . . . . . . . . . . . . . . . 10
3.6 Precision (Prec) . . . . . . . . . . . . . . . . . . . . . 10
3.7 Root Delay . . . . . . . . . . . . . . . . . . . . . . . . 10
3.8 Root Dispersion . . . . . . . . . . . . . . . . . . . . . 10
3.9 Reference Identifier . . . . . . . . . . . . . . . . . . . 11
3.10 Reference Timestamp . . . . . . . . . . . . . . . . . . 12
3.11 Originate Timestamp . . . . . . . . . . . . . . . . . . 12
3.12 Receive Timestamp . . . . . . . . . . . . . . . . . . . 12
3.13 Transmit Timestamp . . . . . . . . . . . . . . . . . . . 12
3.14 NTPv4 Extension Fields . . . . . . . . . . . . . . . . . 12
3.15 Authentication (optional) . . . . . . . . . . . . . . . 13
4. NTP Protocol Operation . . . . . . . . . . . . . . . . . . . 14
5. SNTP Protocol Operation . . . . . . . . . . . . . . . . . . 14
6. NTP Server Operations . . . . . . . . . . . . . . . . . . . 15
7. NTP Client Operations . . . . . . . . . . . . . . . . . . . 17
8. NTP Symmetric Peer Operations . . . . . . . . . . . . . . . 20
9. NTPv4 Security . . . . . . . . . . . . . . . . . . . . . . . 20
9.1 Session Keys and Cookies . . . . . . . . . . . . . . . . . 20
9.2 Session Key List Generation . . . . . . . . . . . . . . . 21
9.3 Sending Messages . . . . . . . . . . . . . . . . . . . . . 21
9.4 Receiving Messages . . . . . . . . . . . . . . . . . . . . 21
9.5 Autokey Protocol Exchanges . . . . . . . . . . . . . . . . 22
10. Dynamic Server Discovery . . . . . . . . . . . . . . . . . . 23
11. NTP Control Messages . . . . . . . . . . . . . . . . . . . . 24
11.1 NTP Control Message Format . . . . . . . . . . . . . . . 26
11.2 Status Words . . . . . . . . . . . . . . . . . . . . . . 27
11.2.1 System Status Word . . . . . . . . . . . . . . . . . 28
11.2.2 Peer Status Word . . . . . . . . . . . . . . . . . . 29
11.2.3 Clock Status Word . . . . . . . . . . . . . . . . . 31
11.2.4 Error Status Word . . . . . . . . . . . . . . . . . 32
11.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . 33
12. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . . . 35
13. Security Considerations . . . . . . . . . . . . . . . . . . 36
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
15. Other Considerations . . . . . . . . . . . . . . . . . . . . 37
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 RFC 1305 The Network Time Protocol Version 3 (NTPv3) specified in [1] has been
[MIL92] has been widely used to synchronize computer clocks in the widely used to synchronize computer clocks in the global Internet.
global Internet. It provides comprehensive mechanisms to access It provides comprehensive mechanisms to access national time and
national time and frequency dissemination services, organize the NTP frequency dissemination services, organize the NTP subnet of servers
subnet of servers and clients and adjust the system clock in each and clients and adjust the system clock in each participant. In most
participant. In most places of the Internet of today, NTP provides places of the Internet of today, NTP provides accuracies of 1-50 ms,
accuracies of 1-50 ms, depending on the characteristics of the depending on the characteristics of the synchronization source and
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 and over a wide range of network jitter and clock
frequency wander characteristics. Many users of NTP in the Internet frequency wander characteristics. Many users of NTP in the Internet
of today use a software distribution available from www.ntp.org. The of today use a software distribution available from www.ntp.org. The
distribution, which includes the full suite of NTP options, distribution, which includes the full suite of NTP options,
mitigation algorithms and security schemes, is a relatively complex, mitigation algorithms and security schemes, is a relatively complex,
real-time application. While the software has been ported to a wide real-time application. While the software has been ported to a wide
variety of hardware platforms ranging from personal computers to variety of hardware platforms ranging from personal computers to
supercomputers, its sheer size and complexity is not appropriate for supercomputers, its sheer size and complexity is not appropriate for
many applications. This facilitated the development of the Simple many applications. This facilitated the development of the Simple
Network Time Protocol Version 4 (SNTPv4) as described in RFC 2030 Network Time Protocol Version 4 (SNTPv4) as described in [2].
[MIL96].
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 2030 (SNTPv4 is a
subset of NTPv4). subset of NTPv4).
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
skipping to change at page 4, line 4 skipping to change at page 4, line 52
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 and OSI addressing. The
only significant difference between the NTPv3 and NTPv4 header 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 source. In NTPv4 providing IPv6 and OSI addressing, primary servers
servers use the same clock identifier, but secondary servers use the use the same clock identifier, but secondary servers use the first 32
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 [ISO86]. Each NTP packet is transmitted as the TS- used as in [3]. Each NTP packet is transmitted as the TS- Userdata
Userdata parameter of a T-UNITDATA Request primitive. Alternately, parameter of a T-UNITDATA Request primitive. Alternately, the header
the header can be encapsulated in a TPDU which itself is transported can be encapsulated in a TPDU which itself is transported using UDP,
using UDP, as described in RFC-1240 [DOB91]. It is not advised that as described in [4]. It is not advised that NTP be operated at the
NTP be operated at the upper layers of the OSI stack, such as might upper layers of the OSI stack, such as might be inferred from [5], as
be inferred from RFC-1698 [FUR94], as this could seriously degrade this could seriously degrade accuracy. With the header formats
accuracy. With the header formats defined in this memo, it is in defined in this memo, it is in principle possible to interwork
principle possible to interwork between servers and clients of one between servers and clients of one protocol family and another,
protocol family and another, although the practical difficulties may although the practical difficulties may make this inadvisable.
make this inadvisable.
In the following, indented paragraphs such as this one contain In the following, indented paragraphs such as this one contain
information not required by the formal protocol specification, but information not required by the formal protocol specification, but
considered good practice in protocol implementations. considered good practice in protocol implementations.
This document is organized as follows. Section 2 describes how the This document is organized as follows.Section 2 describes the NTP
protocol works, the various modes and how IP addresses and UDP ports timestamp format and Section 3 the NTP message format. Section 4
are used. Section 3 describes the NTP timestamp format and Section 4 provides general NTP protocol details, with the subset SNTP described
the NTP message format. Section 5 summarizes NTP client operations in Section 5. This is followed by specific sections on Server
and Section 6 summarizes NTP server operations. Section 7 summarizes (Section 6), Client(Section 7), and Symmetric Peer(Section 8) modes
the optional security mechanisms present within the NTPv4 protocol. of operation.Section 9 summarizes the optional security mechanisms
Section 8 summarizes operation and management issues. Section 9 present within the NTPv4 protocol. Section 10 defines the new
describes the kiss-o'-death message, whose functionality is mechanism for server discovery. Section 11 describes the control and
similar to the ICMP Source Quench and ICMP Destination Unreachable management mechanism for NTP. Section 12 describes the kiss-o'-death
messages. Section 10 presents NTPv4 security considerations. message, whose functionality is similar to the ICMP Source Quench and
Section 11 presents various other considerations when implementing ICMP Destination Unreachable messages. Section 13 presents NTPv4
and/or configuring NTPv4. security considerations and Section 14 discusses IANA Considerations.
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.
2. NTP Protocol Operation 2. NTP Timestamp
Unless excepted in context, reference to broadcast address means IPv4
broadcast address, IPv4 multicast group address or IPv6 site-local
scope address. Further information on the broadcast/multicast model
is in RFC 1112 [DEE89]. Details of address format, scoping rules,
etc., are beyond the scope of this memo. NTPv4 can operate with
either unicast (point to point), broadcast (point to multipoint) or
anycast (multipoint to point) addressing modes. A unicast client
sends a request to a designated server at its unicast address and
expects a reply from which it can determine the time and, optionally,
the roundtrip delay and clock offset relative to the server. A
broadcast server periodically sends an unsolicited message to a
designated broadcast address. A broadcast client listens on this
address and ordinarily sends no requests.
Anycast is designed for use with a set of cooperating servers whose
addresses are not known beforehand. The anycast client sends an
ordinary NTP client request to a designated broadcast address. One
or more anycast servers listen on that address. Upon receiving a
request, an anycast server sends an ordinary NTP server reply to the
client. The client then binds to the server from which the first
such message was received and continues operation with that unicast
addresses. Subsequent replies from other anycast servers are
ignored.
Broadcast servers should respond to client unicast requests, as
well as send unsolicited broadcast messages. 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.
The client and server addresses are assigned following the usual
IPv4, IPv6 or OSI conventions. For NTP multicast, the IANA has
reserved the IPv4 group address 224.0.1.1 and the IPv6 group address
ending :101, with prefix determined by scoping rules. The NTP
broadcast address for OSI has yet to be determined. Notwithstanding
the IANA reserved addresses, other multicast addresses can be used
which do not conflict with others assigned in scope. In the case of
IPv4 multicast or IPv6 broadcast addresses, the client must implement
the Internet Group Management Protocol (IGMP) as described in RFC-
3376 [CAIN02], in order that the local router joins the multicast
group and relays messages to the IPv4 or IPv6 multicast group. The
scoping, routing and group membership procedures are determined by
considerations beyond the scope of this memo.
It is important to adjust the time-to-live (TTL) field in the IP
header of multicast messages to a reasonable value in order to
limit the network resources used by this (and any other) multicast
service. Only multicast clients in scope will receive multicast
server messages. Only cooperating anycast servers in scope will
reply to a client request. The engineering principles which
determine the proper values to be used are beyond the scope of
this memo.
While not integral to the NTP specification, it is intended that
IP broadcast addresses will be used primarily in IP subnets and
LAN segments including a fully functional NTP server with a number
of dependent NTP broadcast clients on the same subnet, while IP
multicast group addresses will be used only in cases where the TTL
is engineered specifically for each service domain.
3. NTP Timestamp
NTPv4 uses the standard NTP timestamp format described in RFC-1305. NTPv4 uses the standard NTP timestamp format described in RFC 1305.
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 most significant end. Unless specified otherwise, all quantities are
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.
NTP timestamps are represented as a 64-bit unsigned fixed-point NTP timestamps are represented as a 64-bit unsigned fixed-point
number, in seconds relative to 0h on 1 January 1900. The integer 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 part is in the first 32 bits and the fraction part in the last 32
last 32 bits. In the fraction part, the non-significant low order bits. In the fraction part, the non-significant low order bits are
bits are not specified and ordinarily set to 0. The NTP timestamp not specified and ordinarily set to 0. The NTP timestamp format is
format is as shown in Figure 1. defined as:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. NTP Timestamp Format
It is advisable to fill the non-significant low order bits of the It is advisable to fill the non-significant low order bits of the
timestamp with a random, unbiased bitstring, both to avoid timestamp with a random, unbiased bitstring, both to avoid systematic
systematic roundoff errors and as a means of loop detection and roundoff errors and as a means of loop detection and replay detection
replay detection (see below). It is important that the bitstring (see below). It is important that the bitstring be unpredictable by
be unpredictable by a intruder. One way of doing this is to a intruder. One way of doing this is to generate a random 128-bit
generate a random 128-bit bitstring at startup. After that, each bitstring at startup. After that, each time the system clock is read
time the system clock is read the string consisting of the the string consisting of the timestamp and bitstring is hashed with
timestamp and bitstring is hashed with the MD5 algorithm, then the the MD5 algorithm, then the non-significant bits of the timestamp are
non-significant bits of the timestamp are copied from the result. copied from the result.
The NTP format allows convenient multiple-precision arithmetic and The NTP format allows convenient multiple-precision arithmetic and
conversion to UDP/TIME message (seconds), but does complicate the conversion to UDP/TIME message (seconds), but does complicate the
conversion to ICMP Timestamp message (milliseconds) and Unix time conversion to ICMP Timestamp message (milliseconds) and Unix time
values (seconds and microseconds or seconds and nanoseconds). The values (seconds and microseconds or seconds and nanoseconds). The
maximum number that can be represented is 4,294,967,295 seconds with maximum number that can be represented is 4,294,967,295 seconds with
a precision of about 232 picoseconds, which should be adequate for a precision of about 232 picoseconds, which should be adequate for
even the most exotic requirements. 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
skipping to change at page 7, line 19 skipping to change at page 7, line 5
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 reckoned from
6h 28m 16s UTC on 7 February 2036. Note that when calculating the 6h 28m 16s UTC on 7 February 2036. Note that when calculating the
correspondence, 2000 is a leap year and leap seconds are not included correspondence, 2000 is a leap year and leap seconds are not included
in the reckoning. in the reckoning.
4. NTP Message Formats 3. NTP Message Formats
Both NTP and SNTP are clients of the User Datagram Protocol (UDP) Both NTP and SNTP are layered above of the User Datagram Protocol
[POS80], which itself is a client of the Internet Protocol (IP) (UDP) [6], which itself is layered on the Internet Protocol (IP) [7]
[DAR81] [DER98]. The structure of the IP and UDP headers is described [8]. The structure of the IP and UDP headers is described in the
in the cited specification documents and will not be detailed further cited specification documents and will not be detailed further here.
here. The UDP port number assigned to NTP is 123, which should be The UDP port number assigned to NTP is 123, which should be used in
used in both the Source Port and Destination Port fields in the UDP both the Source Port and Destination Port fields in the UDP header.
header. The remaining UDP header fields should be set as described in The remaining UDP header fields should be set as described in the
the specification. specification.
Below is a description of the NTPv4 message format, which follows Below is a description of the NTPv4 message format, which follows the
the IP and UDP headers. This format is identical to that described in IP and UDP headers. This format is identical to that described in
RFC 1305, with the exception of the contents of the reference RFC 1305, with the exception of the contents of the reference
identifier field. The header fields are defined in Figure 2. identifier field. The header fields are defined as:
Leap Indicator (LI):
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 day of insertion and reset after 00:00 on the following day.
This causes the number of seconds (rollover interval) in the day
of insertion to be increased or decreased by one. In the case of
primary servers the bits are set by operator intervention, while
in the case of secondary servers the bits are set by the protocol.
The possible values of the LI field, and corresponding meanings,
are as follows:
LI Meaning
---------------------------------------------
0 no warning
1 last minute has 61 seconds
2 last minute has 59 seconds)
3 alarm condition (clock not synchronized)
On startup, servers set this field to 3 (clock not synchronized)
and 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 that value again, even if all synchronization sources
become unreachable or defective.
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 49 skipping to change at page 8, line 46
| | | |
+ Extension Field 2 (Optional) + + Extension Field 2 (Optional) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. Authentication . . Authentication .
. (Optional) (160 bits) . . (Optional) (160 bits) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 NTP Message Format 3.1 Leap Indicator (LI)
Version (VN):
This is a three-bit integer indicating the NTP/SNTP version
number, currently 4. If necessary to distinguish between IPv4,
IPv6 and OSI, the encapsulating context must be inspected.
Mode: This is a two-bit field indicating an impending leap second to be
This is a three-bit number indicating the protocol mode. The inserted in the NTP timescale. The bits are set before 23:59 on the
values are defined as follows: day of insertion and reset after 00:00 on the following day. This
causes the number of seconds (rollover interval) in the day of
insertion to be increased or decreased by one. In the case of
primary servers the bits are set by operator intervention, while in
the case of secondary servers the bits are set by the protocol. The
possible values of the LI field, and corresponding meanings, are as
follows:
Mode Meaning +----+------------------------------------------+
------------------------------------ | LI | Meaning |
0 reserved +----+------------------------------------------+
1 symmetric active | 0 | no warning |
2 symmetric passive | 1 | last minute has 61 seconds |
3 client | 2 | last minute has 59 seconds |
4 server | 3 | alarm condition (clock not synchronized) |
5 broadcast +----+------------------------------------------+
6 reserved for NTP control message
7 reserved for private use
In unicast and anycast modes, the client sets this field to 3 On startup, servers set this field to 3 (clock not synchronized) and
(client) in the request and the server sets it to 4 (server) in set this field to some other value when synchronized to the primary
the reply. In broadcast mode, the server sets this field to 5 reference clock. Once set to other than 3, the field is never set to
that value again, even if all synchronization sources become
unreachable or defective.
3.2 Version (VN)
This is a three-bit integer indicating the NTP/SNTP version number,
currently 4. If necessary to distinguish between IPv4, IPv6 and OSI,
the encapsulating context must be inspected.
3.3 Mode
This is a three-bit number indicating the protocol mode. The values
are defined as follows:
+------+----------------------------------+
| Mode | Meaning |
+------+----------------------------------+
| 0 | reserved |
| 1 | symmetric active |
| 2 | symmetric passive |
| 3 | client |
| 4 | server |
| 5 | broadcast |
| 6 | reserved for NTP control message |
| 7 | reserved for private use |
+------+----------------------------------+
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). (broadcast).
Stratum (Strat): 3.4 Stratum (Strat)
This is a eight-bit unsigned integer indicating the stratum.
This field is significant only in SNTP server messages, where the
values are defined as follows:
Stratum Meaning This is a eight-bit unsigned integer indicating the stratum. This
---------------------------------------------- field is significant only in SNTP server messages, where the values
0 kiss-o'-death message are defined as follows:
1 primary reference (e.g., synchronized by radio clock)
2-15 secondary reference (synchronized by NTP or SNTP) +---------+-------------------------------------------------------+
16-255 reserved | Stratum | Meaning |
+---------+-------------------------------------------------------+
| 0 | kiss-o'-death message |
| 1 | primary reference (e.g., synchronized by radio clock) |
| 2-15 | secondary reference (synchronized by NTP or SNTP) |
| 16-255 | reserved |
+---------+-------------------------------------------------------+
3.5 Poll Interval (Poll)
Poll Interval (Poll):
This is an eight-bit unsigned integer used as an exponent of two, This is an eight-bit unsigned integer used as an exponent of two,
where the resulting value is the maximum interval between where the resulting value is the maximum interval between successive
successive messages in seconds. This field is significant only in messages in seconds. This field is significant only in SNTP server
SNTP server messages, where the values range from 4 (16 s) to 17 messages, where the values range from 4 (16 s) to 17 (131,072 s -
(131,072 s - about 36 h). about 36 h).
Precision (Prec): 3.6 Precision (Prec)
This is an eight-bit signed integer used as an exponent of
two, where 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.
Root Delay: This is an eight-bit signed integer used as an exponent of two, where
This is a 32-bit signed fixed-point number indicating the the resulting value is the precision of the system clock in seconds.
total roundtrip delay to the primary reference source, in seconds This field is significant only in server messages, where the values
with fraction point between bits 15 and 16. Note that this range from -6 for mains-frequency clocks to -20 for microsecond
variable can take on both positive and negative values, depending clocks found in some workstations.
on the relative time and frequency offsets. This field is
significant only in server messages, where the values range from
negative values of a few milliseconds to positive values of
several hundred milliseconds.
Root Dispersion: 3.7 Root Delay
This is a 32-bit unsigned fixed-point number indicating the
nominal error relative to the primary reference source, in seconds This is a 32-bit signed fixed-point number indicating the total
with fraction point between bits 15 and 16. This field is roundtrip delay to the primary reference source, in seconds with
significant only in server messages, where the values range from fraction point between bits 15 and 16. Note that this variable can
zero to several hundred milliseconds. take on both positive and negative values, depending on the relative
time and frequency offsets. This field is significant only in server
messages, where the values range from negative values of a few
milliseconds to positive values of several hundred milliseconds.
3.8 Root Dispersion
This is a 32-bit unsigned fixed-point number indicating the nominal
error relative to the primary reference source, in seconds with
fraction point between bits 15 and 16. This field is significant
only in server messages, where the values range from zero to several
hundred milliseconds.
3.9 Reference Identifier
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 source. This field is significant only in server messages, where for
for stratum 0 (kiss-o'-death message) and 1 (primary server), the stratum 0 (kiss-o'-death message) and 1 (primary server), the value
value is a four-character ASCII string, left justified and zero is a four-character ASCII string, left justified and zero padded to
padded to 32 bits. For IPv4 secondary servers,the value is the 32 bits. For IPv4 secondary servers,the value is the 32-bit IPv4
32-bit IPv4 address of the synchronization source. For IPv6 and address of the synchronization source. For IPv6 and OSI secondary
OSI secondary servers, the value is the first 32 bits of the MD5 servers, the value is the first 32 bits of the MD5 hash of the IPv6
hash of the IPv6 or NSAP address of the synchronization source. or NSAP address of the synchronization source.
Primary (stratum 1) servers set this field to a code identifying Primary (stratum 1) servers set this field to a code identifying the
the external reference source according to the below table. external reference source according to the below table.
Code External Reference Source +------+----------------------------------------------------------+
---------------------------------------------------------------- | Code | External Reference Source |
LOCL uncalibrated local clock +------+----------------------------------------------------------+
CESM calibrated Cesium clock | LOCL | uncalibrated local clock |
RBDM calibrated Rubidium clock | CESM | calibrated Cesium clock |
PPS calibrated quartz clock or other pulse-per-second | RBDM | calibrated Rubidium clock |
source | 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 | ACTS | NIST telephone modem service |
USNO USNO telephone modem service | USNO | USNO telephone modem service |
PTB PTB (Germany) telephone modem service | PTB | PTB (Germany) telephone modem service |
TDF Allouis (France) Radio 164 kHz | TDF | Allouis (France) Radio 164 kHz |
DCF Mainflingen (Germany) Radio 77.5 kHz | DCF | Mainflingen (Germany) Radio 77.5 kHz |
MSF Rugby (UK) Radio 60 kHz | MSF | Rugby (UK) Radio 60 kHz |
WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz | WWV | Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz |
WWVB Boulder (US) Radio 60 kHz | WWVB | Boulder (US) Radio 60 kHz |
WWVH Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz | WWVH | Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz |
CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz | CHU | Ottawa (Canada) Radio 3330, 7335, 14670 kHz |
LORC LORAN-C radionavigation system | LORC | LORAN-C radionavigation system |
OMEG OMEGA radionavigation system | OMEG | OMEGA radionavigation system |
GPS Global Positioning Service | GPS | Global Positioning Service |
+------+----------------------------------------------------------+
If the external reference is one of those listed, the associated If the external reference is one of those listed, the associated code
code should be used. Codes for sources not listed can be contrived should be used. Codes for sources not listed can be contrived as
as appropriate. appropriate.
In previous NTP and SNTP secondary servers and clients this field In previous NTP and SNTP secondary servers and clients this field was
was often used to walk-back the synchronization subnet to the root often used to walk-back the synchronization subnet to the root
(primary server) for management purposes. (primary server) for management purposes.
Reference Timestamp: 3.10 Reference Timestamp
This field is significant only in server messages, where the value
is the time at which the system clock was last set or corrected, This field is significant only in server messages, where the value is
in 64-bit timestamp format. the time at which the system clock was last set or corrected, in 64-
bit timestamp format.
3.11 Originate Timestamp
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 timestamp format.
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 timestamp format.
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 timestamp format.
NTPv4 Extension Fields: 3.14 NTPv4 Extension Fields
NTPv4 defines new extension field formats. These fields are NTPv4 defines new extension field formats. These fields are
processed in order and may be transmitted with or without value processed in order and may be transmitted with or without value
fields. The last field is padded to a 64-bit boundary, all others fields. The last field is padded to a 64-bit boundary, all others
fields are padded to 32-bit boundaries. The field length is for fields are padded to 32-bit boundaries. The field length is for all
all payload and padding. 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 12, line 42 skipping to change at page 13, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | | Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. Signature . . Signature .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) | | Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 NTPv4 Extension Field 3.15 Authentication (optional)
Authentication (optional):
The authentication field format is shown in Figure 4. The authentication field format is defined as:
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 +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Optional Authentication Field
When the NTP authentication scheme is implemented, the 16-bit Key When the NTP authentication scheme is implemented, the 16-bit Key
Identifier and 128-bit Message Digest fields contain the Message Identifier and 128-bit Message Digest fields contain the Message
Authentication Code (MAC) information which uses an MD5 cryptosum Authentication Code (MAC) information which uses an MD5 cryptosum of
of NTP header plus extension fields. NTP header plus extension fields.
5. NTP Client Operations
An NTP client can operate in unicast, broadcast or anycast modes. In
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
broadcast client mode it sends no request and waits for a broadcast
(NTP mode 5) from one or more broadcast servers. In anycast mode,
the client sends a request (NTP mode 3) to a designated broadcast
address and expects a reply (NTP mode 4) from one or more anycast
servers. The client uses the first reply received to establish the
particular server for subsequent unicast operations. Later replies
from this server (duplicates) or any other server are ignored. Other
than the selection of address in the request, the operations of
anycast and unicast clients are identical.
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 9.
A unicast or anycast client initializes the NTP message header, sends
the 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 header fields shown above are set to 0, except the Mode, VN and
optional Transmit Timestamp fields.
NTP and SNTP clients set the mode field to 3 (client) for unicast and
anycast requests. They set the VN field to any version number
supported by the server selected by configuration or discovery and
can interoperate with all previous version NTP and SNTP servers.
Servers reply with the same version as the request, so the VN field
of the request also specifies the VN field of the reply. An NTP
client can specify the earliest acceptable version on the expectation
that any server of that or later version will respond. NTPv4 servers
are backwards compatible with NTPv3 as defined in RFC 1305, NTPv2
as defined in RFC 1119 [MIL89], and NTPv1 as defined in RFC 1059
[MIL88]. NTPv0 defined in RFC 959 [MIL85] is not supported.
In unicast and anycast modes, the Transmit Timestamp field in the
request should be set to the time of day according to the client
clock in NTP timestamp format. This allows a simple calculation to
determine the propagation delay between the server and client and to
align the system clock generally within a few tens of milliseconds
relative to the server. In addition, this provides a simple method
to verify that the server reply is in fact a legitimate response to
the specific client request and avoid replays. In broadcast mode,
the client has no information to calculate the propagation delay or
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.
Field Name Unicast/Anycast Broadcast
Request Reply
---------------------------------------------------------------
LI 0 0-3 0-3
VN 1-4 copied from 1-4
request
Mode 1 or 3 2 or 4 5
Stratum 0 0-15 0-15
Poll 0 ignore ignore
Precision 0 ignore ignore 4. NTP Protocol Operation
Root Delay 0 ignore ignore The NTP protocol defines three operational roles, Client, Server, and
Symmetric Peer. Clients request or receive time unsolicited from
Servers. Servers respond to requests or send periodic time updates
to Clients. Symmetric Peers exchange time data bidirectionally. A
given NTP implementation can operate in any or all of these modes.
Root Dispersion 0 ignore ignore NTP messages make use of two different communication modes, one to
one and one to many, commonly referred to as unicast and broadcast.
For the purposes of this document, the term broadcast is interpreted
to mean any available one to many mechanism. For IPv4 this equates
to either IPv4 broadcast or IPv4 multicast. For IPv6 this equates to
IPv6 multicast. For OSI this XXXXX. For this purpose, IANA has
allocated the IPv4 multicast address 224.0.1.1 and the IPv6 multicast
address ending :101, with prefix determined by scoping rules. The
NTP broadcast address for OSI has yet to be determined.
Reference Identifier 0 ignore ignore It is important to adjust the time-to-live (TTL) field in the IP
header of multicast messages to a reasonable value in order to
limit the network resources used by this (and any other) multicast
service. Only multicast clients in scope will receive multicast
server messages. Only cooperating anycast servers in scope will
reply to a client request. The engineering principles which
determine the proper values to be used are beyond the scope of
this memo.
Reference Timestamp 0 ignore ignore While not integral to the NTP specification, it is intended that
IP broadcast addresses will be used primarily in IP subnets and
LAN segments including a fully functional NTP server with a number
of dependent NTP broadcast clients on the same subnet, while IP
multicast group addresses will be used only in cases where the TTL
is engineered specifically for each service domain.
Originate Timestamp 0 (see text) ignore 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
of 123.
Receive Timestamp 0 (see text) ignore 5. SNTP Protocol Operation
Transmit Timestamp (see text) nonzero nonzero 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.
Authenticator optional optional optional Without the complexity and state required by the Symmetric Peer, SNTP
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.
[Need to add a similar table for symmetric modes of operation] Note that SNTP servers normally operate as primary (stratum 1)
servers. While operating at higher strata (up to 15) and at the
same time synchronizing to an external source such as a GPS
receiver is not forbidden, this is strongly discouraged.
6. NTP Server Operations 6. NTP Server Operations
An NTP server operating with either an NTP or SNTP client of the same Fundamentally, the NTP Server role consists of listening for client
or previous versions retains no persistent state. Since a SNTP requests, and providing time and associated details as a response.
server ordinarily does not implement the full suite of grooming and Additionally, a Server can provide time and associated details
mitigation algorithms intended to support redundant servers and periodically via a broadcast mechanism. An NTP server operating with
diverse network paths, a SNTP server should be operated only in either an NTP or SNTP client of the same or previous versions retains
conjunction with a source of external synchronization, such as a no persistent state.
reliable radio clock or telephone modem. In this case it operates as
a primary (stratum 1) server.
An NTP server can operate with any unicast, anycast or broadcast An NTP server can communicate via unicast, broadcast, or both. A
address or any combination of these addresses. A unicast or anycast server receiving a unicast request (NTP mode 3), modifies fields in
server receives a request (NTP mode 3), modifies certain fields in the NTP header as described below, and sends a reply (NTP mode 4),
the NTP header, and sends a reply (NTP mode 4), possibly using the possibly using the same message buffer as the request. When
same message buffer as the request. A anycast server listens on the operating in a broadcast mode, unsolicited messages (NTP mode 5) with
designated broadcast address, but uses its own unicast IP address in field values as described below are normally sent at intervals
the source address field of the reply. Other than the selection of ranging from 64 s to 1024 s, depending on the expected frequency
address in the reply, the operations of anycast and unicast servers
are identical. Broadcast messages are normally sent at poll
intervals 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.
Unicast and anycast servers copy the VN and Poll fields of the A broadcast server may or may not send messages if not synchronized
request intact to the reply and set the Stratum field to 1. to a correctly operating source, but the preferred option is to
transmit, since this allows reachability to be determined regardless
of synchronization state.
Note that SNTP servers normally operate as primary (stratum 1) The Leap Indicator (LI) is set to 3 (unsynchronized) if the server
servers. While operating at higher strata (up to 15) and at the has never synchronized to a reference source. Once synchronized, the
same time synchronizing to an external source such as a GPS LI field is set to one of the other three values and remains at the
receiver is not forbidden, this is strongly discouraged. last value set even if the reference source becomes unreachable or
turns faulty.
If the Mode field of the request is 3 (client), the reply is set to 4 The Version (VN) is copied from the request packet, if responding to
(server). If this field is set to 1 (symmetric active), the reply is a unicast request. For broadcast, this is set to 4.
set to 2 (symmetric passive). This allows clients configured in
either client (NTP mode 3) or symmetric active (NTP mode 1) to
interoperate successfully, even if configured in possibly suboptimal
ways. For any other value in the Mode field, the request is
discarded. In broadcast (unsolicited) mode, the VN field is set to
4, the Mode field is set to 5 (broadcast), and the Poll field set to
the nearest integer base-2 logarithm of the poll interval.
Note that it is highly desirable that a broadcast server also The Mode is set to Server (4) if in response to a unicast request.
supports unicast clients. This is so a potential broadcast client For broadcast, this is set to Broadcast (5).
can calculate the propagation delay using a client/server exchange
prior to switching to broadcast client (listen-only) mode. A
anycast server by design also is a unicast server. There does not
seem to be a great advantage for a server to operate as both
broadcast and anycast at the same time, although the protocol
specification does not forbid it.
A broadcast or anycast server may or may not respond if not The Stratum field to the server's current stratum, if synchronized.
synchronized to a correctly operating reference source, but the If synchronized to a reference source the Stratum field is set to 1.
preferred option is to respond, since this allows reachability to be If unsynchronized this field is set to 0.
determined regardless of synchronization state. If the server has
never synchronized to a reference source, the LI field is set to 3
(unsynchronized). Once synchronized to a reference source, 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 turns
faulty.
If synchronized to a reference source the Stratum field is set to 1 The Poll field is coppied from the request, if responding to a
and the Reference Identifier field is set to the ASCII source unicast request. For broadcast, this is set to the nearest integer
identifier shown in Figure 2. If not synchronized, the Stratum field base-2 logarithm of the poll interval.
is set to zero and the Reference Identifier field set to an ASCII
error identifier described below. In broadcast mode, the server
sends broadcasts only if synchronized to a correctly operating
reference source.
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. For all practical cases it is computed as the
negative base-2 logarithm of the number of significant bits to the negative base-2 logarithm of the number of significant bits to the
right of the decimal point in the NTP timestamp format. The Root right of the decimal point in the NTP timestamp format. The Root
Delay and Root Dispersion fields are set to 0 for a primary server; Delay and Root Dispersion fields are set to 0 for a primary server;
optionally, the Root Dispersion field can be set to a value optionally, the Root Dispersion field can be set to a value
corresponding to the maximum expected error of the radio clock corresponding to the maximum expected error of the radio clock
itself. itself.
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
source, left justified and zero padded to 32bits. For IPv4 secondary
servers,the value is the 32-bit IPv4 address of the synchronization
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
synchronization source. If unsynchronized, it is set to an ASCII
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 message is a reply to a are set to zero with one exception. If the server is synchronized
previously received client request, the Transmit Timestamp field of and up, the Transmit Timestamp field of the request is copied
the request is copied unchanged to the Originate Timestamp field of unchanged to the Originate Timestamp field of the reply. It is
the reply. It is important that this field be copied intact, as an important that this field be copied intact, as an NTP or SNTP client
NTP or SNTP client uses it to avoid bogus messages. 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 are 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. The following table summarizes these actions. messages.
Field Name Unicast/Anycast Broadcast
Request Reply
----------------------------------------------------------------
LI ignore as needed as needed
VN 1-4 copied from 4
request
Mode 1 or 3 2 or 4 5
Stratum ignore 1 1
Poll ignore copied from log2 poll The following table summarizes these actions:
request interval
Precision ignore -log2 server -log2 server +----------------+----------------+----------------+----------------+
significant significant | Field Name | Unicast | Unicast Reply | Broadcast |
bits bits | | Request | | |
+----------------+----------------+----------------+----------------+
| LI | ignore | as needed | as needed |
| VN | 1-4 | copied from | 4 |
| | | request | |
| Mode | 1 or 3 | 2 or 4 | 5 |
| Stratum | ignore | 1 | 1 |
| Poll | ignore | copied from | log2 poll |
| | | request | interval |
| Precision | ignore | -log2 server | -log2 server |
| | | significant | significant |
| | | bits | bits |
| Root Delay | ignore | 0 | 0 |
| Root | ignore | 0 | 0 |
| Dispersion | | | |
| Reference | ignore | source ident | source ident |
| Identifier | | | |
| Reference | ignore | time of last | time of last |
| Timestamp | | src. update | src. update |
| Originate | ignore | copied from | 0 |
| Timestamp | | xmit timestamp | |
| Receive | ignore | time of day | 0 |
| Timestamp | | | |
| Transmit | (see text) | time of day | time of day |
| Timestamp | | | |
| Authenticator | optional | optional | optional |
+----------------+----------------+----------------+----------------+
Root Delay ignore 0 0 Broadcast servers should respond to client unicast requests, as
well as send unsolicited broadcast messages. 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
Root Dispersion ignore 0 0 7. NTP Client Operations
Reference Identifier ignore source ident source ident The role of an NTP client is to determine the current time (and
associated information) from an NTP server. This can be done
actively, by sending a unicast request to a configured server, or
passively by listening on a known address for periodic server
messages.
Reference Timestamp ignore time of last time of last An NTP client can operate in unicast or broadcast modes. In unicast
source update source update 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
broadcast client mode it sends no request and waits for a broadcast
(NTP mode 5) from one or more broadcast servers.
Originate Timestamp ignore copied from 0 Broadcast clients may send unicast requests in order to measure
transmit the network propagation delay between the server and client and
timestamp 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.
Receive Timestamp ignore time of day 0 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.
Transmit Timestamp (see text) time of day time of day A unicast client initializes the NTP message header, sends the
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
header fields shown in Section 3 are set to 0, except the Mode, VN
and optional Transmit Timestamp fields.
Authenticator optional optional optional NTP and SNTP clients set the mode field to 3 (client) for unicast and
anycast requests. They set the VN field to any version number
supported by the server selected by configuration or discovery and
can interoperate with all previous version NTP and SNTP servers.
Servers reply with the same version as the request, so the VN field
of the request also specifies the VN field of the reply. An NTP
client can specify the earliest acceptable version on the expectation
that any server of that or later version will respond. NTPv4 servers
are backwards compatible with NTPv3 as defined in RFC 1305, NTPv2 as
defined in [9], and NTPv1 as defined in [10]. NTPv0 defined in [11]
is not supported.
[Need to add a similar table for symmetric modes of operation] 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
timestamp format. This allows a simple calculation to determine the
propagation delay between the server and client and to align the
system clock generally within a few tens of milliseconds relative to
the server. In addition, this provides a simple method to verify
that the server reply is in fact a legitimate response to the
specific client request and avoid replays. In broadcast mode, the
client has no information to calculate the propagation delay or
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.
7. NTPv4 Security The following table summarizes the proper setting of these fields:
+----------------+----------------+----------------+----------------+
| Field Name | Unicast | Unicast Reply | Broadcast |
| | Request | | |
+----------------+----------------+----------------+----------------+
| LI | 0 | 0-3 | 0-3 |
| VN | 1-4 | copied from | 1-4 |
| | | request | |
| Mode | 1 or 3 | 2 or 4 | 5 |
| Stratum | 0 | 0-15 | 0-15 |
| Poll | 0 | ignore | ignore |
| Precision | 0 | ignore | ignore |
| Root Delay | 0 | ignore | ignore |
| Root | 0 | ignore | ignore |
| Dispersion | | | |
| Reference | 0 | ignore | ignore |
| Identifier | | | |
| Reference | 0 | ignore | ignore |
| Timestamp | | | |
| Originate | 0 | (see text) | ignore |
| Timestamp | | | |
| Receive | 0 | (see text) | ignore |
| Timestamp | | | |
| Transmit | (see text) | nonzero | nonzero |
| Timestamp | | | |
| Authenticator | optional | optional | optional |
+----------------+----------------+----------------+----------------+
8. NTP Symmetric Peer Operations
NTP Symmetric Peer mode is intended for configurations where a set of
low-stratum peers operate as mutual backups for each other. Each
peer normally operates with oner or more sources, such as a reference
clock, or a subset of primary or secondry servers known to be
reliable or authentic.
Symmetric Peer mode is exclusive to the NTP protocol and is
specifically excluded from SNTP operation.
9. NTPv4 Security
NTPv4 employs the Autokey security protocol, which works NTPv4 employs the Autokey security protocol, which works
independently for each client, with tentative outcomes confirmed only independently for each client, with tentative outcomes confirmed only
after both succeed. Public keys and certificates are obtained and after both succeed. Public keys and certificates are obtained and
verified relatively infrequently using X.509 certificates and verified relatively infrequently using X.509 certificates and
certificate trails. Session keys are derived from public keys. Each certificate trails. Session keys are derived from public keys. Each
NTP message is individually authenticated using the session key and NTP message is individually authenticated using the session key and
the message digest (keyed MD5). A proventic trail is a sequence of the message digest (keyed MD5). A proventic trail is a sequence of
NTP servers each synchronized and cryptographically veritifed to the NTP servers each synchronized and cryptographically veritifed to the
next lower stratum server and ending on one or more trusted servers. next lower stratum server and ending on one or more trusted servers.
Proventic trails are constructed from each server to the trusted Proventic trails are constructed from each server to the trusted
servers at decreasing stratum levels. When server time and at least servers at decreasing stratum levels. When server time and at least
one proventic trail are verified, the peer is admitted to the one proventic trail are verified, the peer is admitted to the
population and used to synchronize the system clock. population and used to synchronize the system clock.
7.1 Session Keys and Cookies 9.1 Session Keys and Cookies
NTPv4 session keys have four 32-bit words, as shown in Figure 5. NTPv4 session keys have four 32-bit words, as shown in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address | | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address | | Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 5 skipping to change at page 21, line 19
values. values.
The server generates a cookie unique to the client and server The server generates a cookie unique to the client and server
addresses and its own private value. It returns the cookie, addresses and its own private value. It returns the cookie,
signature, and timestampe to the client in an extension field. The signature, and timestampe to the client in an extension field. The
cookie is transmitted from server to client encrypted by the client cookie is transmitted from server to client encrypted by the client
public key. The server uses the cookie to validate requests and public key. The server uses the cookie to validate requests and
construct replies. The client uses the cookie to validate the reply construct replies. The client uses the cookie to validate the reply
and checks that the request key ID matches the reply key ID. and checks that the request key ID matches the reply key ID.
7.2 Session Key List Generation 9.2 Session Key List Generation
The server rolls a random 32-bit seed as the initial key ID and The server rolls a random 32-bit seed as the initial key ID and
selects the cookie. Messages with a zero cookie contain only public selects the cookie. Messages with a zero cookie contain only public
values. The initial session key is constructed using the given values. The initial session key is constructed using the given
addressses, cookie and initial key ID. The session key value is addressses, cookie and initial key ID. The session key value is
stored in the key cache. The next session key is constructed using 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 first four octets of the session key value as the new key ID.
The server continues to generate the full list. The final index The server continues to generate the full list. The final index
number and last key ID are provided in an extension field with number and last key ID are provided in an extension field with
signature and timestamp. signature and timestamp.
7.3 Sending Messages 9.3 Sending Messages
The MAC consists of the MD5 message digest of the NTP header and The MAC consists of the MD5 message digest of the NTP header and
extension fields using the session key ID and value stored in the key 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 cache. The server uses the session key ID list in reverse order and
discards each key value after use. An extension field containing the discards each key value after use. An extension field containing the
last index number and key ID is included in the first packet last index number and key ID is included in the first packet
transmitted (last on the list). This extension field can be provided 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, upon request at any time. When all entries in the key list are used,
a new one is generated. a new one is generated.
7.4 Receiving Messages 9.4 Receiving Messages
The intent is not to hide the message contents. Rather, the goal is The intent is not to hide the message contents. Rather, the goal is
to verify its source and that it has not been modified in transit. to verify its source and that it has not been modified in transit.
The MAC message digest is compared with the computed digest of the The MAC message digest is compared with the computed digest of the
NTP header and extension fields using the session key ID in the MAC NTP header and extension fields using the session key ID in the MAC
and the key value computed from the addresses, key ID and cookie. If and the key value computed from the addresses, key ID and cookie. If
the cookie is zero, the message contains public values. Anybody can the cookie is zero, the message contains public values. Anybody can
validate the message or make a valid message containing any values. validate the message or make a valid message containing any values.
If the cookie has been determined by secret means, nobody except the 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. parties to the secret can validate a message or make a valid message.
7.5 Autokey Protocol Exchanges 9.5 Autokey Protocol Exchanges
There are five types of Autokey protocol exchanges: There are five types of Autokey protocol exchanges:
1. Parameter Exchange (ASSOC message): This message exchanges host Parameter Exchange (ASSOC message): This message exchanges host
names, agrees on digest/signature and identity schemes. This names, agrees on digest/signature and identity schemes. This
protocol exchange is unsigned. Optionally, host name/address can protocol exchange is unsigned. Optionally, host name/address can
be verified using reverse-DNS. An initial association request is be verified using reverse-DNS. An initial association request is
sent by the client, sending the host name and status word sent by the client, sending the host name and status word
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest/Signature NID | Client | Ident | Host | | Digest/Signature NID | Client | Ident | Host |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Status Word Format Figure 6 Status Word Format
If the server digest NID and ID scheme agree, the server responds If the server digest NID and ID scheme agree, the server responds
with an association response message, sending host name and with an association response message, sending host name and status
status word. The client, upon agreeing with digest NID and ID word. The client, upon agreeing with digest NID and ID scheme,
scheme, then sends a certificate request. The server responds then sends a certificate request. The server responds with an
with an X.509 certificate and signature. The certificate X.509 certificate and signature. The certificate request/response
request/response cycle repeats as needed. A primary (Stratum 1) cycle repeats as needed. A primary (Stratum 1) certifcate is
certifcate is explicitly trusted and self-signed. Secondary explicitly trusted and self-signed. Secondary certificates are
certificates are signed by the next lower stratum server and signed by the next lower stratum server and validated with its
validated with its public key. public key.
2. Certificate Exchange (CERT message): This exchange is used to Certificate Exchange (CERT message): This exchange is used to
obtain and verify certificates on the trail to a trusted root obtain and verify certificates on the trail to a trusted root
certificate. Certificate exchanges follow the same process as certificate. Certificate exchanges follow the same process as
parameter exchanges. parameter exchanges.
3. Identity Exchange (IFF, GW, and MV messages): This exchange is Identity Exchange (IFF, GW, and MV messages): This exchange is
used to verify server identity using an agreed identity scheme used to verify server identity using an agreed identity scheme
(TC, IFF, GQ, MV). This exchange is a challenge-response scheme. (TC, IFF, GQ, MV). This exchange is a challenge-response scheme.
The client initiates by sending a challenge request. The server The client initiates by sending a challenge request. The server
then provides the challenge response. then provides the challenge response.
4. Values Exchange (COOKIE and AUTO messages): This exchange is used Values Exchange (COOKIE and AUTO messages): This exchange is used
to obtain and verify the cookie, autokey values, and leapseconds to obtain and verify the cookie, autokey values, and leapseconds
table, depending on the association mode (client-server, table, depending on the association mode (client-server,
broadcast, symmetric). For cookie exchanges, the client sends broadcast, symmetric). For cookie exchanges, the client sends its
its public key to the server without signature when not public key to the server without signature when not synchronized.
synchronized. Symmetric active peers send its public key and Symmetric active peers send its public key and signature to
signature to passive peer when synchronized. The server cookie passive peer when synchronized. The server cookie is encrypted
is encrypted from the hash of source/destination addresses, zero from the hash of source/destination addresses, zero key ID, and
key ID, and server private value. A symmetric passive cookie is a server private value. A symmetric passive cookie is a random
random value for every exchange. The server private value is value for every exchange. The server private value is refreshed
refreshed and protocol restarted once per day. For autokey and protocol restarted once per day. For autokey exchanges, the
exchanges, the server generates a key list and signature is server generates a key list and signature is calculated to last
calculated to last about one hour. A client sends requests to about one hour. A client sends requests to the server without
the server without signature when not synchronized. The server signature when not synchronized. The server replies with the last
replies with the last index number and key ID on the list. index number and key ID on the list. Broadcast servers uses AUTO
Broadcast servers uses AUTO response for the first message after response for the first message after regenerating the key and
regenerating the key and ASSOC responses for all other messages. ASSOC responses for all other messages.
5. Signature Exchange (SIGN message): This exchange requests the Signature Exchange (SIGN message): This exchange requests the
server to sign and return a client certificate. The exchange is server to sign and return a client certificate. The exchange is
valid only when the client has synchronized to a proventic source valid only when the client has synchronized to a proventic source
and the server identity has been confirmed. This exchange is and the server identity has been confirmed. This exchange is used
used to authenticate clients to servers, with the server acting to authenticate clients to servers, with the server acting as de
as de facto certificate authority using an encrypted credential facto certificate authority using an encrypted credential scheme.
scheme. The client sends a certificate to the server with or The client sends a certificate to the server with or without
without signature. The server extracts the requested data and signature. The server extracts the requested data and signs that
signs that data with the server private key. The client then data with the server private key. The client then verifies the
verifies the certificate and signature. Subsequently, the client certificate and signature. Subsequently, the client supplies this
supplies this certificate rather than self-signed certificates, certificate rather than self-signed certificates, so clients can
so clients can verify with the server public key. verify with the server public key.
8. Configuration and Management
The means used in the configuration and management of NTP servers 10. Dynamic Server Discovery
and clients is the NTP control and monitoring protocol defined in
RFC 1305.
Unicast clients must be provided with one or more designated server NTPv4 provides a mechanism, commonly known as "Manycast", for a
names or IP addresses. If more than one server is provided, one can client to dynamically discover the existance of one or more servers
be used for active operation and one of the others for backup should with no a-priori knowledge. Once servers are discovered, they are
the active one fail or show an error condition. It is not normally then treated as any other unicast server.
useful to use more than one server at a time, as with millions of
NTP-enabled devices expected in the near future, such use could
result in unnecessary strain on network and server resources.
Broadcast servers and anycast clients must be provided with the TTL A client employing server discovery is configured with MinServers,
and local broadcast or multicast group address. Unicast and anycast the minimum number of desired servers and MaxServers, the maximum
servers and broadcast clients may be configured with a list of number of desired servers. The discovery mechanism is a simple
address-mask pairs for access control, so that only those clients or expanding ring search, using IP multicast with increasing TTLs or Hop
servers known to be trusted will be accepted. Multicast servers and Counts. The multicast address used MUST be scoped to the local site,
clients must implement the IGMP protocol and be provided with the as defined by [12].
local broadcast or multicast group address as well. The
configuration data for cryptographic authentication is beyond the
scope of this memo.
There are several scenarios which provide automatic server discovery The client initiates the discovery process by sending an NTP message
and selection for NTP clients with no pre-specified server to the configured multicast address with an IP TTL or Hop Count of 1.
configuration. For instance a role server with CNAME such as This message has all of the NTP header fields set to 0, except the
pool.ntp.org returns a randomized list of volunteer secondary server Mode, VN and optional Transmit Timestamp fields. The Mode is set to
addresses and the client can select one or more as candidates. For 3. It then starts a retry timer (Default: 64 seconds) and listens
an IP subnet or LAN segment including a NTP or SNTP server, NTP for unicast responses from servers. The source address of any server
clients can be configured as broadcast clients. The same approach responses are treated as newly configured unicast servers, up to a
can be used with multicast servers and clients. In both cases, limit of MaxServers. If the number of discovered servers is less
provision of an access control list is a good way to insure only than MinServers when the retry timer expires, an identical NTP
trusted sources can be used to set the system clock. 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.
In another scenario suitable for an extended network with significant A server configured to provide server discovery will listen on the
network propagation delays, clients can be configured for anycast specified multicast address for discovery messages from clients. If
addresses, both upon initial startup and after some period when the the server is in scope of the current TTL and is itself synchronized
currently selected unicast source has not been heard. Following the to a valid source it replies to the discovery message from the client
defined protocol, the client binds to the server from which the first with an ordinary unicast server message as described in Section 6
reply is received and continues operation in unicast mode.
9. The Kiss-o'-Death Packet 11. NTP Control Messages
In a comprehensive network-management environment, facilities are
presumed available to perform routine NTP control and monitoring
functions, such as setting the leap-indicator bits at the primary
servers, adjusting the various system parameters and monitoring
regular operations. Ordinarily, these functions can be implemented
using a network-management protocol such as SNMP and suitable
extensions to the MIB database. However, in those cases where such
facilities are not available, these functions can be implemented
using special NTP control messages described herein. These messages
are intended for use only in systems where no other management
facilities are available or appropriate, such as in dedicated-
function bus peripherals. Support for these messages is not required
in order to conform to this specification.
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.
The format of the data field is specific to each command or response;
however, in most cases the format is designed to be constructed and
viewed by humans and so is coded in free-form ASCII. This
facilitates the specification and implementation of simple management
tools in the absence of fully evolved network-management facilities.
As in ordinary NTP messages, the authenticator field follows the data
field. If the authenticator is used the data field is zero-padded to
a 32-bit boundary, but the 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
octets; however, some commands or responses may involve more data
than will fit into a single datagram. Accordingly, a simple
reassembly feature is included in which each octet of the message
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
number of octets is inserted in the count field. The more-data (M)
bit is set in all fragments except the last.
Most control functions involve sending a command and receiving a
response, perhaps involving several fragments. The sender chooses a
distinct, nonzero sequence number and sets the status field and R and
E bits to zero. The responder interprets the opcode and additional
information in the data field, updates the status field, sets the R
bit to one and returns the three 32-bit words of the header along
with additional information in the data field. In case of invalid
message format or contents the responder inserts a code in the status
field, sets the R and E bits to one and, optionally, inserts a
diagnostic message in the data field.
Some commands read or write system variables and peer variables for
an association identified in the command. Others read or write
variables associated with a radio clock or other device directly
connected to a source of primary synchronization information. To
identify which type of variable and association a 16-bit association
identifier is used. System variables are indicated by the identifier
zero. As each association is mobilized a unique, nonzero identifier
is created for it. These identifiers are used in a cyclic fashion,
so that the chance of using an old identifier which matches a newly
created association is remote. A management entity can request a
list of current identifiers and subsequently use them to read and
write variables for each association. An attempt to use an expired
identifier results in an exception response, following which the list
can be requested again.
Some exception events, such as when a peer becomes reachable or
unreachable, occur spontaneously and are not necessarily associated
with a command. An implementation may elect to save the event
information for later retrieval or to send an asynchronous response
(called a trap) or both. In case of a trap the IP address and port
number is determined by a previous command and the sequence field is
set as described below. Current status and summary information for
the latest exception event is returned in all normal responses. Bits
in the status field indicate whether an exception has occurred since
the last response and whether more than one exception has occurred.
Commands need not necessarily be sent by an NTP peer, so ordinary
access-control procedures may not apply; however, the optional mask/
match mechanism suggested elsewhere in this document provides the
capability to control access by mode number, so this could be used to
limit access for control messages (mode 6) to selected address
ranges.
11.1 NTP Control Message Format
The format of the NTP Control Message header, which immediately
follows the UDP header, is shown in Figure X. Following is a
description of its fields. Bit positions marked as zero are reserved
and should always be transmitted as zero.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|00 |VN | 6 | REM | Op | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Data (468 Octets Max) .
. .
| | Padding (zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator (optional)(96) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Control Message Format
Version Number (VN): This is a three-bit integer indicating the NTP
version number, currently four (4)
Mode: This is a three-bit integer indicating the mode. It must have
the value 6, indicating an NTP control message.
Response Bit (R): Set to zero for commands, one for responses.
Error Bit (E): Set to zero for normal response, one for error
response.
More Bit (M): Set to zero for last fragment, one for all others.
Operation Code (Op): This is a five-bit integer specifying the
command function. Values currently defined include the following:
+-------+----------------------------------------+
| Value | Meaning |
+-------+----------------------------------------+
| 0 | reserved |
| 1 | read status command/response |
| 2 | read variables command/response |
| 3 | write variables command/response |
| 4 | read clock variables command/response |
| 5 | write clock variables command/response |
| 6 | set trap address/port command/response |
| 7 | trap response |
| 8-31 | reserved |
+-------+----------------------------------------+
Sequence: This is a 16-bit integer indicating the sequence number of
the command or response.
Status: This is a 16-bit code indicating the current status of the
system, peer or clock, with values coded as described in following
sections.
Association ID: This is a 16-bit integer identifying a valid
association.
Offset: This is a 16-bit integer indicating the offset, in octets, of
the first octet in the data area.
Count: This is a 16-bit integer indicating the length of the data
field, in octets.
Data: This contains the message data for the command or response.
The maximum number of data octets is 468.
Authenticator (optional): When the NTP authentication mechanism is
implemented, this contains the authenticator information.
11.2 Status Words
Status words indicate the present status of the system, associations
and clock. They are designed to be interpreted by network-monitoring
programs and are in one of four 16-bit formats shown in Figure
6<$&fig6> and described in this section. System and peer status
words are associated with responses for all commands except the read
clock variables, write clock variables and set trap address/port
commands. The association identifier zero specifies the system
status word, while a nonzero identifier specifies a particular peer
association. The status word returned in response to read clock
variables and write clock variables commands indicates the state of
the clock hardware and decoding software. A special error status
word is used to report malformed command fields or invalid values.
11.2.1 System Status Word
The system status word appears in the status field of the response to
a read status or read variables command with a zero association
identifier. The format of the system status word is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| LI | Clock Source | Count | Code |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
System Status Word
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
day, with bit 0 and bit 1, respectively, coded as follows:
+-------+------------------------------------------+
| Value | Meaning |
+-------+------------------------------------------+
| 00 | no warning |
| 01 | last minute has 61 seconds |
| 10 | last minute has 59 seconds |
| 11 | alarm condition (clock not synchronized) |
+-------+------------------------------------------+
Clock Source: This is a six-bit integer indicating the current
synchronization source, with values coded as follows:
+-------+---------------------------------------------------------+
| Value | Meaning |
+-------+---------------------------------------------------------+
| 0 | unspecified or unknown |
| 1 | Calibrated atomic clock (e.g.,, HP 5061) |
| 2 | VLF (band 4) or LF (band 5) radio (e.g.,, OMEGA,, WWVB) |
| 3 | HF (band 7) radio (e.g.,, CHU,, MSF,, WWV/H) |
| 4 | UHF (band 9) satellite (e.g.,, GOES,, GPS) |
| 5 | local net (e.g.,, DCN,, TSP,, DTS) |
| 6 | UDP/NTP |
| 7 | UDP/TIME |
| 8 | eyeball-and-wristwatch |
| 9 | telephone modem (e.g. NIST) |
| 10-63 | reserved |
+-------+---------------------------------------------------------+
System Event Counter: This is a four-bit integer indicating 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
message. The counter is cleared when returned in the status field of
a response and freezes when it reaches the value 15.
System Event Code: This is a four-bit integer identifying the latest
system exception event, with new values overwriting previous values,
and coded as follows:
+---------------------------------+---------------------------------+
| Value | Meaning |
+---------------------------------+---------------------------------+
| 0 | unspecified |
| 1 | system restart |
| 2 | system or hardware fault |
| 3 | system new status word (leap |
| | bits or synchronization change) |
| 4 | system new synchronization |
| | source or stratum (sys.peer or |
| | sys.stratum change |
| 5 | system clock reset (offset |
| | correction exceeds CLOCK.MAX) |
| 6 | system invalid time or date |
| | (see NTP specification) |
| 7 | system clock exception (see |
| | system clock status word) |
| 8-15 | reserved |
+---------------------------------+---------------------------------+
11.2.2 Peer Status Word
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
also in the list of association identifiers and status words returned
by a read status command with a zero association identifier. The
format of a peer status word is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Peer Status | Sel | Count | Code |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Peer Status Word
Peer Status: This is a five-bit code indicating the status of the
peer determined by the packet procedure, with bits assigned as
follows:
+-------+------------------------------------------+
| Value | Meaning |
+-------+------------------------------------------+
| 0 | configured (peer.config) |
| 1 | authentication enabled (peer.authenable) |
| 2 | authentication okay (peer.authentic) |
| 3 | reachability okay (peer.reach) |
| 4 | reserved |
+-------+------------------------------------------+
Peer Selection (Sel): This is a three-bit integer indicating the
status of the peer determined by the clock-selection procedure, with
values coded as follows:
+---------------------------------+---------------------------------+
| Value | Meaning |
+---------------------------------+---------------------------------+
| 0 | rejected |
| 1 | passed sanity checks |
| 2 | passed correctness checks |
| 3 | passed candidate checks (if |
| | limit check implemented) |
| 4 | passed outlyer checks |
| 5 | current synchronization source; |
| | max distance exceeded (if limit |
| | check implemented) |
| 6 | current synchronization source; |
| | max distance okay |
| 7 | reserved |
+---------------------------------+---------------------------------+
Peer Event Counter: This is a four-bit integer indicating the number
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.
The counter is cleared when returned in the status field of a
response and freezes when it reaches the value 15.
Peer Event Code: This is a four-bit integer identifying the latest
peer exception event, with new values overwriting previous values,
and coded as follows:
+---------------------------------+---------------------------------+
| Value | Meaning |
+---------------------------------+---------------------------------+
| 0 | unspecified |
| 1 | peer IP error |
| 2 | peer authentication failure |
| | (peer.authentic bit was one now |
| | zero) |
| 3 | peer unreachable (peer.reach |
| | was nonzero now zero) |
| 4 | peer reachable (peer.reach was |
| | zero now nonzero) |
| 5 | peer clock exception (see peer |
| | clock status word) |
| 6-15 | reserved |
+---------------------------------+---------------------------------+
11.2.3 Clock Status Word
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
synthetic peer managed by NTP. As in the read status command, 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
supported by the protocol, although many peer clocks can be
supported. A system or peer clock status word appears in the status
field of the response to a read clock variables or write clock
variables command. This word can be considered an extension of the
system status word or the peer status word as appropriate. The
format of the clock status word is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Clock Status | Code |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Clock Status Word
Clock Status: This is an eight-bit integer indicating the current
clock status, with values coded as follows:
+-------+---------------------------------+
| Value | Meaning |
+-------+---------------------------------+
| 0 | clock operating within nominals |
| 1 | reply timeout |
| 2 | bad reply format |
| 3 | hardware or software fault |
| 4 | propagation failure |
| 5 | bad date format or value |
| 6 | bad time format or value |
| 7-255 | reserved |
+-------+---------------------------------+
Clock Event Code: This is an eight-bit integer identifying the latest
clock exception event, with new values overwriting previous values.
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
system or peer clock exception event is declared as appropriate.
11.2.4 Error Status Word
An error status word is returned in the status field of an error
response as the result of invalid message format or contents. Its
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
integer coded as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Error Code | Reserved |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Error Status Word
+-------+----------------------------------+
| Value | Meaning |
+-------+----------------------------------+
| 0 | unspecified |
| 1 | authentication failure |
| 2 | invalid message length or format |
| 3 | invalid opcode |
| 4 | unknown association identifier |
| 5 | unknown variable name |
| 6 | invalid variable value |
| 7 | administratively prohibited |
| 8-255 | reserved |
+-------+----------------------------------+
11.3 Commands
Commands consist of the header and optional data field shown in
Figure 6. When present, the data field contains a list of
identifiers or assignments in the form
<<identifier>>[=<<value>>],<<identifier>>[=<<value>>],...
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
decimal, hexadecimal or string constant in the syntax of the C
programming language. Where no ambiguity exists, the <169>sys.<170>
or <169>peer.<170> prefixes shown in Table 2 or Table 4 can be
suppressed. Whitespace (ASCII nonprinting format effectors) can be
added to improve readability for simple monitoring programs that do
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
the brackets are optional. Timestamps, including reference,
originate, receive and transmit values, as well as the logical clock,
are represented in units of seconds and fractions, preferably in
hexadecimal notation, while delay, offset, dispersion and distance
values are represented in units of milliseconds and fractions,
preferably in decimal notation.All other values are represented
as-is, preferably in decimal notation.
Implementations may define variables other than those listed in Table
2 or Table 3. Called extramural variables, these are distinguished
by the inclusion of some character type other than alphanumeric or
<169>.<170> in the name. For those commands that return a list of
assignments in the response data field, if the command data field is
empty, it is expected that all available variables defined in Table 3
or Table 4 of the NTP specification will be included in the response.
For the read commands, if the command data field is nonempty, an
implementation may choose to process this field to individually
select which variables are to be returned.
Commands are interpreted as follows:
Read Status (1): The command data field is empty or contains a list
of identifiers separated by commas. The command operates in two ways
depending on the value of the association identifier. If this
identifier is nonzero, the response includes the peer identifier and
status word. Optionally, the response data field may contain other
information, such as described in the Read Variables command. If the
association identifier is zero, the response includes the system
identifier (0) and status word, while the data field contains a list
of binary-coded pairs
<<association identifier>> <<status word>>,
one for each currently defined association.
Read Variables (2): The command data field is empty or contains a
list of identifiers separated by commas. If the association
identifier is nonzero, the response includes the requested peer
identifier and status word, while the data field contains a list of
peer variables and values as described above. If the association
identifier is zero, the data field contains a list of system
variables and values. If a peer has been selected as the
synchronization source, the response includes the peer identifier and
status word; otherwise, the response includes the system identifier
(0) and status word.
Write Variables (3): The command data field contains a list of
assignments as described above. The variables are updated as
indicated. The response is as described for the Read Variables
command.
Read Clock Variables (4): The command data field is empty or contains
a list of identifiers separated by commas. The association
identifier selects the system clock variables or peer clock variables
in the same way as in the Read Variables command. The response
includes the requested clock identifier and status word and the data
field contains a list of clock variables and values, including the
last timecode message received from the clock.
Write Clock Variables (5): The command data field contains a list of
assignments as described above. The clock variables are updated as
indicated. The response is as described for the Read Clock Variables
command.
Set Trap Address/Port (6): The command association identifier, status
and data fields are ignored. The address and port number for
subsequent trap messages are taken from the source address and port
of the control message itself. The initial trap counter for trap
response messages is taken from the sequence field of the command.
The response association identifier, status and data fields are not
significant. Implementations should include sanity timeouts which
prevent trap transmissions if the monitoring program does not renew
this information after a lengthy interval.
Trap Response (7): This message is sent when a system, peer or clock
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
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
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
trap the association identifier field is set to that peer and the
status field contains the peer status word. Optional ASCII-coded
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 In the interest of self-preservation, it is important that NTP
servers have a mechanism to supress or otherwise influence the amount servers have a mechanism to supress or otherwise influence the amount
of queries performed by NTP clients. of queries performed by NTP clients.
According to the NTPv3 specification RFC 1305, if the Stratum field According to the NTPv3 specification RFC 1305, if the Stratum field
in the NTP header is 1, indicating a primary server, the Reference in the NTP header is 1, indicating a primary server, the Reference
Identifier field contains an ASCII string identifying the particular Identifier field contains an ASCII string identifying the particular
reference clock type. However, in RFC 1305 nothing is said about the reference clock type. However, in RFC 1305 nothing is said about the
Reference Identifier field if the Stratum field is 0, which is called Reference Identifier field if the Stratum field is 0, which is called
skipping to change at page 24, line 5 skipping to change at page 35, line 35
messages they convey are called kiss codes. The KoD packets got messages they convey are called kiss codes. The KoD packets got
their name because an early use was to tell clients to stop sending their name because an early use was to tell clients to stop sending
packets that violate server access controls. packets that violate server access controls.
The kiss codes can provide useful information for an intelligent The kiss codes can provide useful information for an intelligent
client. These codes are encoded in four-character ASCII strings left client. These codes are encoded in four-character ASCII strings left
justified and zero filled. The strings are designed for character justified and zero filled. The strings are designed for character
displays and log files. A list of the currently-defined kiss codes displays and log files. A list of the currently-defined kiss codes
is in the following table. is in the following table.
Code Meaning +---------------------------------+---------------------------------+
-------------------------------------------------------------- | Code | Meaning |
ACST The association belongs to a anycast server +---------------------------------+---------------------------------+
AUTH Server authentication failed | ACST | The association belongs to an |
AUTO Autokey sequence failed | | anycast server |
BCST The association belongs to a broadcast server | AUTH | Server authentication failed |
CRYP Cryptographic authentication or identification failed | AUTO | Autokey sequence failed |
DENY Access denied by remote server | BCST | The association belongs to a |
DROP Lost peer in symmetric mode | | broadcast server |
RSTR Access denied due to local policy | CRYP | Cryptographic authentication or |
INIT The association has not yet synchronized for the first | | identification failed |
time | DENY | Access denied by remote server |
MCST The association belongs to a manycast server | DROP | Lost peer in symmetric mode |
NKEY No key found. Either the key was never installed or | RSTR | Access denied due to local |
is not trusted | | policy |
RATE Rate exceeded. The server has temporarily denied access | INIT | The association has not yet |
because the client exceeded the rate threshold | | synchronized for the first time |
RMOT Somebody is tinkering with the association from a remote | MCST | The association belongs to a |
host running ntpdc. Not to worry unless some rascal has | | dynamically discovered server |
stolen your keys | NKEY | No key found. Either the key |
STEP A step change in system time has occurred, but the | | was never installed or is not |
association has not yet resynchronized | | 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 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 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 of kiss code, and an alternate server is available. If no alternate
server is available, the client should retransmit using an server is available, the client should retransmit using an
exponential-backoff algorithm described in Section 11. exponential-backoff algorithm described in Section 15.
10. Security Considerations 13. Security Considerations
In the case of NTP as specified herein, there is a very real In the case of NTP as specified herein, there is a very real
vulnerability that NTP broadcast clients can be disrupted by vulnerability that NTP broadcast clients can be disrupted by
misbehaving or hostile SNTP or NTP broadcast servers elsewhere in misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the
the Internet. It is strongly recommended that access controls Internet. It is strongly recommended that access controls and/or
and/or cryptographic authentication means be provided for cryptographic authentication means be provided for additional
additional security in such cases. security in such cases.
While not required in a conforming NTP client implementation, there While not required in a conforming NTP client implementation, there
are a variety of recommended checks that an NTP client can perform are a variety of recommended checks that an NTP client can perform
that are designed to avoid various types of abuse that might happen that are designed to avoid various types of abuse that might happen
as the result of server implementation errors or malicious attack. as the result of server implementation errors or malicious attack.
These recommended checks are as follows: These recommended checks are as follows:
1. When the IP source and destination addresses are available for the When the IP source and destination addresses are available for the
client request, they should match the interchanged addresses in client request, they should match the interchanged addresses in
the server reply. the server reply.
2. When the UDP source and destination ports are available for the When the UDP source and destination ports are available for the
client request, they should match the interchanged ports in the client request, they should match the interchanged ports in the
server reply. server reply.
3. The Originate Timestamp in the server reply should match the The Originate Timestamp in the server reply should match the
Transmit Timestamp used in the client request. Transmit Timestamp used in the client request.
4. The server reply should be discarded if any of the LI, Stratum, or 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 Transmit Timestamp fields are 0 or the Mode field is not 4
(unicast) or 5 (broadcast). (unicast) or 5 (broadcast).
5. A truly paranoid client can check the Root Delay and Root A truly paranoid client can check the Root Delay and Root
Dispersion fields are each greater than or equal to 0 and less Dispersion fields are each greater than or equal to 0 and less
than infinity, where infinity is currently a cozy number like 16 than infinity, where infinity is currently a cozy number like 16
seconds. This check avoids using a server whose synchronization seconds. This check avoids using a server whose synchronization
source has expired for a very long time. source has expired for a very long time.
11. IANA Considerations 14. IANA Considerations
12. Other Considerations 15. Other Considerations
NTP and SNTP clients can consume considerable network and server NTP and SNTP clients can consume considerable network and server
resources if not "good network citizens." There are now consumer resources if not "good network citizens." There are now consumer
Internet commodity devices numbering in the millions that are Internet commodity devices numbering in the millions that are
potential customers of public and private NTP and SNTP servers. potential customers of public and private NTP and SNTP servers.
Recent experience strongly suggests that device designers pay Recent experience strongly suggests that device designers pay
particular attention to minimizing resource impacts, especially if particular attention to minimizing resource impacts, especially if
large numbers of these devices are deployed. The most important large numbers of these devices are deployed. The most important
design consideration is the interval between client requests, called design consideration is the interval between client requests, called
the poll interval. It is extremely important that the design use the the poll interval. It is extremely important that the design use the
maximum poll interval consistent with acceptable accuracy. maximum poll interval consistent with acceptable accuracy.
1. A client MUST NOT use a poll interval less than TBD minutes. A client MUST NOT use a poll interval less than TBD minutes.
2. A client SHOULD increase the poll interval using exponential A client SHOULD increase the poll interval using exponential
backoff as performance permits and especially if the server does backoff as performance permits and especially if the server does
not respond within a reasonable time. not respond within a reasonable time.
3. A client SHOULD use local servers whenever available to avoid A client SHOULD use local servers whenever available to avoid
unnecessary traffic on backbone networks. unnecessary traffic on backbone networks.
4. A client MUST allow the operator to configure the primary and/or A client MUST allow the operator to configure the primary and/or
alternate server names or addresses in addition to or in place of alternate server names or addresses in addition to or in place of
a firmware default IP address. a firmware default IP address.
5. If a firmware default server IP address is provided, it MUST be a If a firmware default server IP address is provided, it MUST be a
server operated by the manufacturer or seller of the device or server operated by the manufacturer or seller of the device or
another server, but only with the operator's permission. another server, but only with the operator's permission.
6. A client SHOULD use the Domain Name System (DNS) to resolve the A client SHOULD use the Domain Name System (DNS) to resolve the
server IP addresses, so the operator can do effective load server IP addresses, so the operator can do effective load
balancing among a server clique and change IP address binding to balancing among a server clique and change IP address binding to
canonical names. canonical names.
7. A client SHOULD re-resolve the server IP address on a periodic 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 intervals, but not less than the time-to-live field in the DNS
response. response.
8. A client SHOULD support the NTP access-refusal mechanism, so that A client SHOULD support the NTP access-refusal mechanism, so that
a server kiss-o'-death reply in response to a client request a server kiss-o'-death reply in response to a client request
causes the client to cease sending requests to that server and to causes the client to cease sending requests to that server and to
switch to an alternate, if available. switch to an alternate, if available.
If the firmware or documentation includes specific server names, the If the firmware or documentation includes specific server names, the
names should be those the manufacturer or seller operates as a names should be those the manufacturer or seller operates as a
customer convenience or those for which specific permission has been customer convenience or those for which specific permission has been
obtained from the operator. A DNS request for a generic server name obtained from the operator. A DNS request for a generic server name
such as ntp.mytimeserver.com results should result in a random such as ntp.mytimeserver.com results should result in a random
selection of server IP addresses available for that purpose. Each selection of server IP addresses available for that purpose. Each
skipping to change at page 26, line 38 skipping to change at page 38, line 35
When selecting candidate SNTP or NTP servers, it is imperative to When selecting candidate SNTP or NTP servers, it is imperative to
respect the server operator's conditions of access. Lists of respect the server operator's conditions of access. Lists of
public servers and their conditions of access are available at public servers and their conditions of access are available at
www.ntp.org. A semi-automatic server discovery scheme using DNS www.ntp.org. A semi-automatic server discovery scheme using DNS
is described at that site. Some ISPs operate public servers, is described at that site. Some ISPs operate public servers,
although finding them via their helpdesks can be difficult. although finding them via their helpdesks can be difficult.
A well behaved client operates as follows (note that steps 2 - 4 A well behaved client operates as follows (note that steps 2 - 4
comprise a synchronization loop): comprise a synchronization loop):
1. Consider the specified frequency tolerance of the system clock Consider the specified frequency tolerance of the system clock
oscillator. Define the required accuracy of the system clock, oscillator. Define the required accuracy of the system clock,
then calculate the maximum timeout. For instance, if the then calculate the maximum timeout. For instance, if the
frequency tolerance is 200 parts-per-million (PPM) and the frequency tolerance is 200 parts-per-million (PPM) and the
required accuracy is one minute, the maximum timeout is about 3.5 required accuracy is one minute, the maximum timeout is about 3.5
days. Use the longest maximum timeout possible given the system days. Use the longest maximum timeout possible given the system
constraints to minimize time server aggregate load, but never less constraints to minimize time server aggregate load, but never less
than 15 minutes. than 15 minutes.
2. When first coming up or after reset, randomize the timeout from When first coming up or after reset, randomize the timeout from
one to five minutes. This is to minimize shock when 3000 PCs are one to five minutes. This is to minimize shock when 3000 PCs are
rebooted at the same time power is restored after a blackout. rebooted at the same time power is restored after a blackout.
Assume at this time the IP address is unknown and the system clock Assume at this time the IP address is unknown and the system clock
is unsynchronized. Otherwise use the timeout value as calculated is unsynchronized. Otherwise use the timeout value as calculated
in previous loop steps. Note that it may be necessary to refrain in previous loop steps. Note that it may be necessary to refrain
from implementing the aforementioned random delay for some classes from implementing the aforementioned random delay for some classes
of ICSA certification. of ICSA certification.
3. When the timer reaches zero, if the IP address is not known, send 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 a DNS query packet; otherwise send a NTP request packet to that
address. If no reply packet has been heard since the last address. If no reply packet has been heard since the last
timeout, double the timeout, but not greater than the maximum timeout, double the timeout, but not greater than the maximum
timeout. If primary and secondary time servers have been timeout. If primary and secondary time servers have been
configured, alternate queries between the primary and secondary configured, alternate queries between the primary and secondary
servers when no successful response has been received. servers when no successful response has been received.
4. If a DNS reply packet is received, save the IP address and 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 continue in step 2. If a KoD packet is received remove that time
server from the list, activate the secondary time server and server from the list, activate the secondary time server and
continue in step 2. If a received packet fails the sanity checks, 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 drop that packet and also continue in step 2. If a valid NTP
packet is received, update the system clock, set the timeout to packet is received, update the system clock, set the timeout to
the maximum, and continue to step 2. the maximum, and continue to step 2.
13. Acknowledgements 16. Acknowledgements
This document has drawn significant material from the document This document has drawn significant material from the document
<draft-mills-sntp-v4-00.txt>. As a result, the authors would like draft-mills-sntp-v4-00.txt. As a result, the authors would like to
to acknowledge D. Plonka of the University of Wisconsin and J. acknowledge D. Plonka of the University of Wisconsin and J.
Montgomery of Netgear, who were significant contributors to that Montgomery of Netgear, who were significant contributors to that
draft. draft.
14. References 17. References
14.1 Normative References 17.1 Normative References
[MIL92] Mills, D., "Network Time Protocol (Version 3) Specification, [1] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992. Implementation", RFC 1305, March 1992.
[MIL96] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for [2] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6, and OSI", RFC 2030, October 1996. IPv4, IPv6 and OSI", RFC 2030, October 1996.
14.2 Informative References 17.2 Informative References
[CAIN02] Cain, B., Deering, S., Kouvalas, I., Fenner, B. and A. [3] International Standards Organization, "International Standards
Thyagarajan, "Internet Group Management Protocol, Version 8602 - Information Processing Systems - OSI: Connectionless
3", RFC 3376, Cereva Networks, October 2002. Transport Protocol Specification.", ISO 8602, December 1986.
[DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791, September [4] Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless
1981. transport services on top of UDP: Version 1", RFC 1240,
June 1991.
[DEE89] Deering, S., "Host extensions for IP multicasting", STD 5, [5] Furniss, P., "Octet Sequences for Upper-Layer OSI to Support
RFC 1112, August 1989. Basic Communications Applications", RFC 1698, October 1994.
[DER98] Deering, S., Hinden R., "Internet Protocol, Version 6 (IPv6)," [6] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
RFC 2460, December 1998. August 1980.
[DOB91] Dobbins, K, Haggerty, W. and C. Shue, "OSI connectionless [7] Postel, J., "Internet Protocol", STD 5, RFC 791,
transport services on top of UDP - Version: 1", RFC 1240, September 1981.
June 1991.
[ISO86] International Standards 8602 - Information Processing [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Systems - OSI: Connectionless Transport Protocol Specification", RFC 2460, December 1998.
Specification. International Standards Organization,
December 1986.
[MIL85] Mills, D., "Network Time Protocol (NTP)", RFC 958, [9] Mills, D., "Network Time Protocol (version 2) specification and
September 1985. implementation", STD 12, RFC 1119, September 1989.
[MIL88] Mills, D., "Network Time Protocol (Version 1) Specification [10] Mills, D., "Network Time Protocol (version 1) specification and
and Implementation", RFC 1059, July 1988. implementation", RFC 1059, July 1988.
[MIL89] Mills, D., "Network Time Protocol (Version 2) Specification [11] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
and Implementation," RFC 1119, September 1989. RFC 959, October 1985.
[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August [12] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
1980. RFC 2365, July 1998.
15. Authors' Addresses [13] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
Jack L. Burbank (Editor) [14] Deering, S., "Host extensions for IP multicasting", STD 5,
The Johns Hopkins University Applied Physics Laboratory (JHU/APL) RFC 1112, August 1989.
11100 Johns Hopkins Road
Laurel, MD 20723
Phone: +1 443-778-7127 Authors' Addresses
EMail: jack.burbank@jhuapl.edu
Jim Martin (co-Editor) Jack Burbank (editor)
Johns Hopkins University Applied Physics Lab
11100 Johns Hopkins Road
Laurel, MD 20723-6099
US
Phone: +1 443 778 7127
Email: jack.burbank@jhuapl.edu
Jim Martin (editor)
Netzwert AG Netzwert AG
An den Treptowers 1 An den Treptowers 1
D-12435 Berlin Berlin 12435
Germany
Phone: +49.30/5 900 800-180 Phone: +49.30/5 900 80-1180
EMail: jim@Netzwert.AG Email: jim@netzwert.ag
Dr. David L. Mills Dr. David L. Mills
The University of Delaware
Electrical Engineering Department
University of Delaware University of Delaware
Newark, DE 19716 Newark, DE 19716
US
Phone: (302) 831-8247 Phone: +1 302 831 8247
EMail: mills@udel.edu Email: mills@udel.edu
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 153 change blocks. 
673 lines changed or deleted 1201 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/