Reference Timestamp ignore time of last time of last
source update source update
Originate Timestamp ignore copied from 0
transmit
timestamp
Receive Timestamp ignore time of day 0
Transmit Timestamp (see text) time of day time of day
Authenticator optional optional optional
There is some latitude on the part of most clients to forgive invalid
timestamps, such as might occur when the server is first coming up or
during periods when the reference source is inoperative. The most
important indicator of an unhealthy server is the Stratum field, in
which a value of 0 indicates an unsynchronized condition. When this
value is displayed, clients should discard the server message,
regardless of the contents of other fields.
7. Configuration and Management
Initial setup for SNTP servers and clients can be done using a web
client, if available, or a serial port, if not. Some folks hoped
that in-service management of NTP and SNTPv4 servers and clients
could be performed using SNMP and a suitable MIB to be published, and
this has happened in some commercial SNTP servers. But, the means
that have been used in the last two decades and probably will be used
in the next is the NTP control and monitoring protocol defined in RFC
1305. Ordinarily, SNTP servers and clients are expected to operate
with little or no site-specific configuration, other than specifying
the client IP address, subnet mask, and gateway.
Unicast clients must be provided with one or more designated server
names or IP addresses. If more than one server is provided, one can
be used for active operation and one of the others for backup should
the active one fail or show an error condition. It is not normally
useful to use more than one server at a time, as with millions of
SNTP-enabled devices expected in the near future, such use would
represent unnecessary drain on network and server resources.
Broadcast servers and manycast clients must be provided with the TTL
and local broadcast or multicast group address. Unicast and manycast
servers and broadcast clients may be configured with a list of
address-mask pairs for access control, so that only those clients or
servers known to be trusted will be accepted. Multicast servers and
clients must implement the IGMP protocol and be provided with the
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 that provide automatic server discovery
and selection for SNTP clients with no pre-specified server
configuration. For instance, a role server with CNAME such as
pool.ntp.org returns a randomized list of volunteer secondary server
addresses, and the client can select one or more as candidates. For
an IP subnet or LAN segment including an NTP or SNTP server, SNTP
clients can be configured as broadcast clients. The same approach
can be used with multicast servers and clients. In both cases,
provision of an access control list is a good way to ensure that only
trusted sources can be used to set the system clock.
In another scenario suitable for an extended network with significant
network propagation delays, clients can be configured for manycast
addresses, both upon initial startup and after some period when the
currently selected unicast source has not been heard. Following the
defined protocol, the client binds to the server from which the first
reply is received and continues operation in unicast mode.
8. The Kiss-o’-Death Packet
In the rambunctious Internet of today, it is imperative that some
means be available to tell a client to stop making requests and to go
somewhere else. A recent experience involved a large number of
home/office routers all configured to use a particular university
time server. Under some error conditions, a substantial fraction of
these routers would send packets at intervals of one second. The
resulting traffic spike was dramatic, and extreme measures were
required to diagnose the problem and to bring it under control. The
conclusion is that clients must respect the means available to
targeted servers to stop them from sending packets.
According to the NTP specification RFC 1305, if the Stratum field in
the NTP header is 1, indicating a primary server, the Reference
Identifier field contains an ASCII string identifying the particular
reference clock type. However, in RFC 1305 nothing is said about the
Reference Identifier field if the Stratum field is 0, which is called
out as "unspecified". However, if the Stratum field is 0, the
Reference Identifier field can be used to convey messages useful for
status reporting and access control. In NTPv4 and SNTPv4, packets of
this kind are called Kiss-o’-Death (KoD) packets, and the ASCII
messages they convey are called kiss codes. The KoD packets got
their name because an early use was to tell clients to stop sending
packets that violate server access controls.
In general, an SNTP client should stop sending to a particular server
if that server returns a reply with a Stratum field of 0, regardless
of kiss code, and an alternate server is available. If no alternate
server is available, the client should retransmit using an
exponential-backoff algorithm described in the next section.
The kiss codes can provide useful information for an intelligent
client. These codes are encoded in four-character ASCII strings left
justified and zero filled. The strings are designed for character
displays and log files. Usually, only a few of these codes can occur
with SNTP clients, including DENY, RSTR, and RATE. Others can occur
more rarely, including INIT and STEP, when the server is in some
special temporary condition. Figure 3 shows a list of the kiss codes
currently defined. These are for informational purposes only; the
list might be modified or extended in the future.
Code Meaning
--------------------------------------------------------------
ACST The association belongs to a anycast server
AUTH Server authentication failed
AUTO Autokey sequence failed
BCST The association belongs to a broadcast server
CRYP Cryptographic authentication or identification failed
DENY Access denied by remote server
DROP Lost peer in symmetric mode
RSTR Access denied due to local policy
INIT The association has not yet synchronized for the first
time
MCST The association belongs to a manycast server
NKEY No key found. Either the key was never installed or
is not trusted
RATE Rate exceeded. The server has temporarily denied access
because the client exceeded the rate threshold
RMOT Somebody is tinkering with the association from a remote
host running ntpdc. Not to worry unless some rascal has
stolen your keys
STEP A step change in system time has occurred, but the
association has not yet resynchronized
Figure 3. Kiss Codes
9. On Being a Good Network Citizen
SNTP and its big brother NTP have been in explosive growth over the
last few years, mirroring the growth of the Internet. Just about
every Internet appliance has some kind of NTP support, including
Windows XP, Cisco routers, embedded controllers, and software systems
of all kinds. This is the first edition of the SNTP RFC where it has
become necessary to lay down rules of engagement in the form of
design criteria for SNTP client implementations. This is necessary
to educate software developers regarding the proper use of Internet
time server resources as the Internet expands and demands on time
servers increase, and to prevent the recurrence of the sort of
problem mentioned above.
10. Best Practices
NTP and SNTP clients can consume considerable network and server
resources if they are not good network citizens. There are now
consumer Internet commodity devices numbering in the millions that
are potential customers of public and private NTP and SNTP servers.
Recent experience strongly suggests that device designers pay
particular attention to minimizing resource impacts, especially if
large numbers of these devices are deployed. The most important
design consideration is the interval between client requests, called
the poll interval. It is extremely important that the design use the
maximum poll interval consistent with acceptable accuracy.
1. A client MUST NOT under any conditions use a poll interval less
than 15 seconds.
2. A client SHOULD increase the poll interval using exponential
backoff as performance permits and especially if the server does
not respond within a reasonable time.
3. A client SHOULD use local servers whenever available to avoid
unnecessary traffic on backbone networks.
4. A client MUST allow the operator to configure the primary and/or
alternate server names or addresses in addition to or in place of
a firmware default IP address.
5. If a firmware default server IP address is provided, it MUST be a
server operated by the manufacturer or seller of the device or
another server, but only with the operator’s permission.
6. A client SHOULD use the Domain Name System (DNS) to resolve the
server IP addresses, so the operator can do effective load
balancing among a server clique and change IP address binding to
canonical names.
7. A client SHOULD re-resolve the server IP address at periodic
intervals, but not at intervals less than the time-to-live field
in the DNS response.
8. A client SHOULD support the NTP access-refusal mechanism so that
a server kiss-o’-death reply in response to a client request
causes the client to cease sending requests to that server and to
switch to an alternate, if available.
The following algorithm can be used as a pattern for specific
implementations. It uses the following variables:
Timer: This is a counter that decrements at a fixed rate. When it
reaches zero, a packet is sent, and the timer is initialized with the
timeout for the next packet.
Maximum timeout: This is the maximum timeout determined from the
given oscillator frequency tolerance and the required accuracy.
Server Name: This is the DNS name of the server. There may be more
than one of them, to be selected by some algorithm not considered
here.
Server IP Address: This is the IPv4, IPv6, or OSI address of the
server.
If the firmware or documentation includes specific server names, the
names should be those the manufacturer or seller operates as a
customer convenience or those for which specific permission has been
obtained from the operator. A DNS request for a generic server name,
such as ntp.mytimeserver.com, should result in a random selection of
server IP addresses available for that purpose. Each time a DNS
request is received, a new randomized list is returned. The client
ordinarily uses the first address on the list.
When candidate SNTP or NTP servers are selected, it is imperative
to respect the server operator’s conditions of access. Lists of
public servers and their conditions of access are available at
www.ntp.org. A semi-automatic server discovery scheme using DNS
is described at that site. Some ISPs operate public servers,
although finding them via their help desks can be difficult.
A well-behaved client operates as follows (note that steps 2-4
constitute a synchronization loop):
1. Consider the specified frequency tolerance of the system clock
oscillator. Define the required accuracy of the system clock,
then calculate the maximum timeout. For instance, if the
frequency tolerance is 200 parts per million (PPM) and the
required accuracy is one minute, the maximum timeout is about 3.5
days. Use the longest maximum timeout possible given the system
constraints to minimize time server aggregate load, but never
make it less than 15 minutes.
2. When the client is first coming up or after reset, randomize the
timeout from one to five minutes. This is to minimize shock when
3000 PCs are rebooted at the same time power is restored after a
blackout. Assume at this time that the IP address is unknown and
that the system clock is unsynchronized. Otherwise, use the
timeout value as calculated in previous loop steps. Note that it
may be necessary to refrain from implementing the aforementioned
random delay for some classes of International Computer Security
Association (ICSA) certification.
3. When the timer reaches zero, if the IP address is not known, send
a DNS query packet; otherwise, send an NTP request packet to that
address. If no reply packet has been heard since the last
timeout, double the timeout, but do not make it greater than the
maximum timeout. If primary and secondary time servers have been
configured, alternate queries between the primary and secondary
servers when no successful response has been received.
4. If a DNS reply packet is received, save the IP address and
continue at step 2. If a KoD packet is received, remove that
time server from the list, activate the secondary time server,
and continue at step 2. If a received packet fails the sanity
checks, drop that packet and also continue at step 2. If a valid
NTP packet is received, update the system clock, set the timeout
to the maximum, and continue at step 2.
11. Security Considerations
Without cryptographic authentication, SNTPv4 service is vulnerable to
disruption 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. This document includes protocol provisions for
adding such security mechanisms, but it does not define the
mechanisms themselves. A separate document [MIL03] in preparation
will define a cryptographic security mechanism for SNTP.
12. Acknowledgements
Jeff Learman was helpful in developing the OSI model for this
protocol. Ajit Thyagarajan provided valuable suggestions and
corrections.
13. Contributors
D. Plonka
J. Montgomery
14. Informative References
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[COL94] Colella, R., Callon, R., Gardner, E., and Y. Rekhter,
"Guidelines for OSI NSAP Allocation in the Internet", RFC
1629, May 1994.
[DEE89] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[DEE98] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[DOB91] Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless
transport services on top of UDP: Version 1", RFC 1240, June
1991.
[FUR94] Furniss, P., "Octet Sequences for Upper-Layer OSI to Support
Basic Communications Applications", RFC 1698, October 1994.
[ISO86] International Standards 8602 - Information Processing
Systems - OSI: Connectionless Transport Protocol
Specification. International Standards Organization,
December 1986.
[MIL92] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992.
[MIL03] Mills, D., "The Autokey Security Architecture, Protocol and
Algorithms", http://eecis.udel.edu/~mills/database/reports/
stime/stime.pdf, August 2003.
[PAR93] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
Service", RFC 1546, November 1993.
[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[POS83] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC
868, May 1983.
[SRI99] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC 2663,
August 1999.
[SRI01] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
Author’s Address
David L. Mills
Electrical and Computer Engineering Department
University of Delaware
Newark, DE 19716
Phone: (302) 831-8247
EMail: mills@udel.edu
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).