Request for Comments: 4330 University of Delaware
Obsoletes: 2030, 1769 January 2006
Category: Informational
Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memorandum describes the Simple Network Time Protocol Version 4
(SNTPv4), which is a subset of the Network Time Protocol (NTP) used
to synchronize computer clocks in the Internet. SNTPv4 can be used
when the ultimate performance of a full NTP implementation based on
RFC 1305 is neither needed nor justified. When operating with
current and previous NTP and SNTP versions, SNTPv4 requires no
changes to the specifications or known implementations, but rather
clarifies certain design features that allow operation in a simple,
stateless remote-procedure call (RPC) mode with accuracy and
reliability expectations similar to the UDP/TIME protocol described
in RFC 868.
This memorandum obsoletes RFC 1769, which describes SNTP Version 3
(SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to
correct certain inconsistencies in the previous documents and to
clarify header formats and protocol operations for NTPv3 (IPv4) and
SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A
further purpose is to provide guidance for home and business client
implementations for routers and other consumer devices to protect the
server population from abuse. A working knowledge of the NTPv3
specification, RFC 1305, is not required for an implementation of
SNTP.
Table of Contents
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................5
2. Operating Modes and Addressing ..................................5
3. NTP Timestamp Format ............................................6
4. Message Format ..................................................8
5. SNTP Client Operations .........................................13
6. SNTP Server Operations .........................................16
7. Configuration and Management ...................................19
8. The Kiss-o’-Death Packet .......................................20
9. On Being a Good Network Citizen ................................21
10. Best Practices ................................................21
11. Security Considerations .......................................24
12. Acknowledgements ..............................................24
13. Contributors ..................................................24
14. Informative References ........................................25
1. Introduction
The Network Time Protocol Version 3 (NTPv3), specified in RFC 1305
[MIL92], is widely used to synchronize computer clocks in the global
Internet. It provides comprehensive mechanisms to access national
time and frequency dissemination services, organize the NTP subnet of
servers and clients, and adjust the system clock in each participant.
In most places of the Internet of today, NTP provides accuracies of
1-50 ms, depending on the characteristics of the synchronization
source and network paths.
RFC 1305 specifies the NTP protocol machine in terms of events,
states, transition functions and actions, and engineered algorithms
to improve the timekeeping quality and to mitigate several
synchronization sources, some of which may be faulty. To achieve
accuracies in the low milliseconds over paths spanning major portions
of the Internet, these intricate algorithms, or their functional
equivalents, are necessary. In many applications, accuracies on the
order of significant fractions of a second are acceptable. In simple
home router applications, accuracies of up to a minute may suffice.
In such cases, simpler protocols, such as the Time Protocol specified
in RFC 868 [POS83], have been used for this purpose. These protocols
involve an RPC exchange where the client requests the time of day and
the server returns it in seconds past a known reference epoch.
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
frequency wander characteristics. Many users of NTP in the Internet
of today use a software distribution available from www.ntp.org. The
distribution, which includes the full suite of NTP options,
mitigation algorithms, and security schemes, is a relatively complex,
real-time application. Although the software has been ported to a
wide variety of hardware platforms ranging from personal computers to
supercomputers, its sheer size and complexity is not appropriate for
many applications. Accordingly, it is useful to explore alternative
strategies using simpler software appropriate for less stringent
accuracy expectations.
This memo describes the Simple Network Time Protocol Version 4
(SNTPv4), which is a simplified access paradigm for servers and
clients using current and previous versions of NTP and SNTP. The
access paradigm is identical to the UDP/TIME Protocol, and, in fact,
it should be easy to adapt a UDP/TIME client implementation, say for
a personal computer, to operate using SNTP. Moreover, SNTP is also
designed to operate in a dedicated server configuration including an
integrated radio clock. With careful design and control of the
various latencies in the system, which is practical in a dedicated
design, it is possible to deliver time accurate on the order of
microseconds.
The only significant protocol change in SNTPv4 from previous SNTP
versions is a modified header interpretation to accommodate Internet
Protocol Version 6 (IPv6) (RFC 2460) and OSI (RFC 1629) addressing.
However, SNTPv4 includes certain optional extensions to the basic NTP
Version 3 (NTPv3) model, including a manycast mode and a public-key-
based authentication scheme designed specifically for broadcast and
manycast applications. Although the manycast mode is described in
this memo, the authentication scheme is described in another RFC to
be submitted later. Until such time that a definitive NTPv4
specification is published, the manycast and authentication features
should be considered provisional. In addition, this memo introduces
the kiss-o’-death message, which can be used by servers to suppress
client requests as circumstances require.
When operating with current and previous versions of NTP and SNTP,
SNTPv4 requires no changes to the protocol or implementations now
running or likely to be implemented specifically for future NTP or
SNTP versions. The NTP and SNTP packet formats are the same, and the
arithmetic operations to calculate the client time, clock offset, and
roundtrip delay are the same. To an NTP or SNTP server, NTP and SNTP
clients are indistinguishable; to an NTP or SNTP client, NTP and SNTP
servers are indistinguishable. Like NTP servers operating in non-
symmetric modes, SNTP servers are stateless and can support large
numbers of clients; however, unlike most NTP clients, SNTP clients
normally operate with only a single server at a time.
The full degree of reliability ordinarily expected of NTP servers is
possible only using redundant sources, diverse paths, and the crafted
algorithms of a full NTP implementation. It is strongly recommended
that SNTP clients be used only at the extremities of the
synchronization subnet. SNTP clients should operate only at the
leaves (highest stratum) of the subnet and in configurations where no
NTP or SNTP client is dependent on another SNTP client for
synchronization. SNTP servers should operate only at the root
(stratum 1) of the subnet, and then only in configurations where no
other source of synchronization other than a reliable radio clock or
telephone modem is available.
An important provision in this memo is the interpretation of certain
NTP header fields that provide for IPv6 [DEE98] and OSI [COL94]
addressing. The only significant difference between the NTP and
SNTPv4 header formats is the four-octet Reference Identifier field,
which is used primarily to detect and avoid synchronization loops.
In all NTP and SNTP versions providing IPv4 addressing, primary
servers use a four-character ASCII reference clock identifier in this
field, whereas secondary servers use the 32-bit IPv4 address of the
synchronization source. In SNTPv4 providing IPv6 and OSI addressing,
primary servers use the same clock identifier, but secondary servers
use the first 32 bits of the MD5 hash of the IPv6 or NSAP address of
the synchronization source. A further use of this field is when the
server sends a kiss-o’-death message, documented later in this memo.
NTP Version 4 (NTPv4), now in deployment, but not yet the subject
of a standards document, uses the same Reference Identifier field
as SNTPv4.
In the case of OSI, the Connectionless Transport Service (CLTS) is
used as in [ISO86]. Each SNTP packet is transmitted as the TS-
Userdata parameter of a T-UNITDATA Request primitive. Alternately,
the header can be encapsulated in a Transport Protocol Data Unit
(TPDU), which itself is transported using UDP, as described in RFC
1240 [DOB91]. It is not advised that NTP be operated at the upper
layers of the OSI stack, such as might be inferred from RFC 1698
[FUR94], as this could seriously degrade accuracy. With the header
formats defined in this memo, it is in principle possible to
interwork between servers and clients of one protocol family and
another, although the practical difficulties may make this
inadvisable.
In the following, indented paragraphs such as this one contain
information not required by the formal protocol specification, but
considered good practice in protocol implementations.
This memo is organized as follows. Section 2 describes how the
protocol works, the various modes, and how IP addresses and UDP ports
are used. Section 3 describes the NTP timestamp format, and Section
4 the NTP message format. Section 5 summarizes SNTP client
operations, and Section 6 summarizes SNTP server operations. Section
7 summarizes operation and management issues. Section 8 describes
the kiss-o’-death message, newly minted with functions similar to the
ICMP Source Quench and ICMP Destination Unreachable messages.
Section 9 summarizes design issues important for good network
citizenry and presents an example algorithm designed to give good
reliability while minimizing network and server resource demands.
1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [BRA97].
2. Operating Modes and Addressing
Unless excepted in context, a reference to broadcast address means
IPv4 broadcast address, IPv4 multicast group address, or IPv6 address
of appropriate scope. 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. SNTPv4 can operate
with either unicast (point to point), broadcast (point to
multipoint), or manycast (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.
Manycast is an extension of the anycast paradigm described in RFC
1546 [PAR93]. It is designed for use with a set of cooperating
servers whose addresses are not known beforehand. The manycast
client sends an ordinary NTP client request to a designated broadcast
address. One or more manycast servers listen on that address. Upon
receiving a request, a manycast server sends an ordinary NTP server
reply to the client. The client then mobilizes an association for
each server found and continues operation with all of them.
Subsequently, the NTP mitigation algorithms operate to cast out all
except the best three.
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 address ending
:101 with appropriate scope. The NTP broadcast address for OSI has
yet to be determined. Notwithstanding the IANA reserved addresses,
other multicast addresses can be used that do not conflict with
others assigned in scope. 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 manycast servers in scope will
reply to a client request. The engineering principles that
determine the proper values to be used are beyond the scope of
this memo.
In the case of SNTP as specified herein, there is a very real
vulnerability that SNTP broadcast clients can be disrupted by
misbehaving or hostile SNTP or NTP broadcast servers elsewhere in
the Internet. It is strongly recommended that access controls
and/or cryptographic authentication means be provided for
additional security in such cases.
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 SNTP broadcast clients on the
same subnet, and that IP multicast group addresses will be used
only in cases where the TTL is engineered specifically for each
service domain. However, these uses are not integral to the SNTP
specification.
3. NTP Timestamp Format
SNTP uses the standard NTP timestamp format described in RFC 1305 and
previous versions of that document. In conformance with standard
Internet practice, NTP data are specified as integer or fixed-point
quantities, with bits numbered in big-endian fashion from 0 starting
at the left or most significant end. Unless specified otherwise, all
quantities are unsigned and may occupy the full field width with an
implied 0 preceding bit 0.
Because NTP timestamps are cherished data and, in fact, represent the
main product of the protocol, a special timestamp format has been
established. NTP timestamps are represented as a 64-bit unsigned
fixed-point number, in seconds relative to 0h on 1 January 1900. The
integer part is in the first 32 bits, and the fraction part in the
last 32 bits. In the fraction part, the non-significant low-order
bits are not specified and are ordinarily set to 0.
It is advisable to fill the non-significant low-order bits of the
timestamp with a random, unbiased bitstring, both to avoid
systematic roundoff errors and to provide loop detection and
replay detection (see below). It is important that the bitstring
be unpredictable by an intruder. One way of doing this is to
generate a random 128-bit bitstring at startup. After that, each
time the system clock is read, the string consisting of the
timestamp and bitstring is hashed with the MD5 algorithm, then the
non-significant bits of the timestamp are copied from the result.
The NTP format allows convenient multiple-precision arithmetic and
conversion to UDP/TIME message (seconds), but does complicate the
conversion to ICMP Timestamp message (milliseconds) and Unix time
values (seconds and microseconds or seconds and nanoseconds). The
maximum number that can be represented is 4,294,967,295 seconds with
a precision of about 232 picoseconds, which should be adequate for
even the most exotic requirements.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Fraction (0-padded) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that since some time in 1968 (second 2,147,483,648), the most
significant bit (bit 0 of the integer part) has been set and that the
64-bit field will overflow some time in 2036 (second 4,294,967,296).
There will exist a 232-picosecond interval, henceforth ignored, every
136 years when the 64-bit field will be 0, which by convention is
interpreted as an invalid or unavailable timestamp.
As the NTP timestamp format has been in use for over 20 years, it
is possible that it will be in use 32 years from now, when the
seconds field overflows. As it is probably inappropriate to
archive NTP timestamps before bit 0 was set in 1968, a convenient
way to extend the useful life of NTP timestamps is the following
convention: 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 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 correspondence, 2000 is a leap year, and
leap seconds are not included in the reckoning.
The arithmetic calculations used by NTP to determine the clock
offset and roundtrip delay require the client time to be within 34
years of the server time before the client is launched. As the
time since the Unix base 1970 is now more than 34 years, means
must be available to initialize the clock at a date closer to the
present, either with a time-of-year (TOY) chip or from firmware.
4. Message Format
Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
specified in RFC 768 [POS80]. The structures of the IP and UDP
headers are described in the cited specification documents and will
not be detailed further here. The UDP port number assigned by the
IANA to NTP is 123. The SNTP client should use this value in the UDP
Destination Port field for client request messages. The Source Port
field of these messages can be any nonzero value chosen for
identification or multiplexing purposes. The server interchanges
these fields for the corresponding reply messages.
This differs from the RFC 2030 specifications, which required both
the source and destination ports to be 123. The intent of this
change is to allow the identification of particular client
implementations (which are now allowed to use unreserved port
numbers, including ones of their choosing) and to attain
compatibility with Network Address Port Translation (NAPT)
described in RFC 2663 [SRI99] and RFC 3022 [SRI01].
Figure 1 is a description of the NTP and SNTP message format, which
follows the IP and UDP headers in the message. This format is
identical to the NTP message format described in RFC 1305, with the
exception of the Reference Identifier field described below. For
SNTP client messages, most of these fields are zero or initialized
with pre-specified data. For completeness, the function of each
field is briefly summarized below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originate Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transmit Timestamp (64) |
| |