NTP Version 4 Release Notes
Alice's Adventures in
Wonderland, by Lewis Carroll, illustrations by Sir John Tenniel
NTP Version 4 Release Notes
This release of the NTP Version 4 (NTPv4) daemon for Unix incorporates
new features and refinements to the NTP Version 3 (NTPv3) algorithms.
However, it continues the tradition of retaining backwards compatibility
with older versions. The NTPv4 version has been under development for
quite a while and isn't finished yet. In fact, quite a number of NTPv4
features have already been retrofitted in the current NTPv3, although
this version is not actively maintained by the NTPv4 developer's group.
The primary purpose of this release is to verify the remaining new code
compiles and runs in the various architectures, operating systems and
hardware complement that can't be verified here. Of particular interest
are Windows 2000, VMS and various reference clock drivers. As always,
corrections and bugfixes are warmly received, especially in the form of
context diffs.
This note summarizes the differences between this software release of
NTPv4, called ntp-4.x.x, and the previous NTPv3 version, called
xntp3-5.x.x
- Most of the extensive calculations are now done using 64-bit
floating-point format, rather than 64-bit fixed-point format. The
motivation for this is to reduce size, improve speed and avoid messy
bounds checking. Workstations of today are much faster than when the
original NTP version was designed in the early 1980s, and it is rare to
find a processor architecture that does not support it. The fixed-point
format is still used with raw timestamps, in order to retain the full
precision of about 212 picoseconds. However, the algorithms which
process raw timestamps all produce fixed-point differences before
converting to double. The differences are ordinarily quite small
so can be expressed without loss of accuracy in double format.
- The clock discipline algorithm has been redesigned to improve
accuracy, reduce the impact of network jitter and allow an increase in
poll intervals to well over one day with only moderate sacrifice in
accuracy. The NTPv4 design allows servers to increase the poll intervals
even when synchronized directly to the peer. In NTPv3 the poll interval
in such cases was clamped to the minimum, usually 64 s. For those
servers with hundreds of clients, the new design can dramatically reduce
the network load.
- A burst-mode feature is available which
results in good accuracy with intermittent connections typical of PPP
and ISDN services. When enabled, at each poll interval the server sends
eight messages over the next 30-s interval and processes them in a
batch. However, the interval between the first and subsequent messages
is about 20 s in order for a dialup modem to complete the call. Outlyers
due to initial dial-up delays, etc., are avoided and the server
synchronizes with its peer generally within 30 s.
- In addition to the NTPv3 authentication scheme, which uses
private-key cryptography, a new NTPv4 autokey
authentication scheme is available. Autokey uses public-key
technology and avoids the need to distribute keys by separate means. The
design is such that full accuracy is available without degradation due
to processing demands of the public-key routines. It can be used in any
of the NTP association modes, but is most useful in broadcast/multicast
modes.
- NTPv4 includes two new association modes which in most
applications can avoid per-host configuration altogether. Both of these
are based on multicast technology. They provide for automatic discovery
and configuration of servers and clients. In multicast
mode, a server sends a message at fixed intervals using specified
multicast addresses, while clients listen on these addresses. Upon
receiving the message, a client exchanges several messages with the
server in order to calibrate the multicast propagation delay between the
client and server. In manycast mode, a client
sends a message and expects one or more servers to reply. Using
engineered algorithms, the client selects an appropriate subset of
servers from the messages received and continues in ordinary
client/server operation with them. The manycast scheme can provide
somewhat better accuracy than the multicast scheme at the price of
additional network overhead.
- The reference clock driver interface is smaller, more rational
and more accurate. Support for pulse-per-second (PPS) signals has been
extended to all drivers as an intrinsic function. Most of the drivers in
NTPv3 have been converted to this interface, but some, including the
PARSE subinterface, have yet to be overhauled. New drivers have been
added for several GPS receivers now on the market for a total of 37
drivers. Drivers for the Canadian standard time and frequency station
CHU, the US standard time and frequency stations WWV/H and for IRIG
signals have been updated and capabilities added to allow direct
connection of these signals to the Sun audio port
/dev/audio.
- In all except a very few cases, all timing intervals are
randomized, so that the tendency for NTPv3 to bunch messages, especially
with a large number of configured associations, is minimized.
- In NTPv3 a large number of weeds and useless code had grown over
the years since the original NTPv1 code was implemented almost ten years
ago. Using a powerful weedwacker, much of the shrubbery has been
removed, with effect a substantial reduction in size of almost 40
percent.
- The entire distribution has been converted to gnu
automake, which should greatly ease the task of porting to new and
different programming environments, as well as reduce the incidence of
bugs due to improper handling of idiosyncratic kernel functions.
Nasty Surprises
There are a few things different about this release that have changed
since the latest NTP Version 3 release. Following are a few things to
worry about:
- As required by Defense Trade Regulations (DTR), the cryptographic
routines supporting the Data Encryption Standard (DES) has been removed
from the export version of the distribution. These routines are readily
available in most countries from RSA Laboratories. Directions for their
use are in the Building and Installing the
Distribution page.
- As the result of the above, the ./authstuff directory,
intended as a development and testing aid for porting cryptographic
routines to exotic architectures, has been removed. Developers should
note the NTP authentication routines use the interface defined in the
rsaref2.0 package available from RSA laboratories.
- The enable and disable commands have a few changes in their
arguments see the ntpd Configuration
Options page for details.
- The scheme for enabling the ppsclock line
discipline/streams module has changed. Formerly, it was enabled by
setting fudge flag3 for the serial port connected to the PPS
signal. Now, there is an explicit command pps used to designate
the device name. See the Reference Clock
Options page for details.
- While in fact not a new problem, some obscure option combinations
require the server and peer commands to follow the
others; in particular, the enable and pps commands
should precede these commands.
Caveats
This release has been compiled and tested on several systems, including
SunOS 4.1.3, Solaris 2.5.1-2.8, Alpha 4.0, Ultrix 4.4, Linux, FreeBSD
3.4 and HP-UX 10.02. It has been compiled and tested on Windows NT, but
not yet on any other Windows version or for VMS. We are relying on the
NTP volunteer corps to do that. Known problems are summarized below:
- The latest NTPv4 ntpdc does not work with previous
versions of ntpd and previous versions of ntpdc do not
work with latest ntpd. This situation is regrettable and may be
fixed in future; however, it is necessary in order for the autokey
function to retrieve canonical names and certificates from directory
services such as Secure DNS.
- To work properly in all cases, the enable and
pps commands, if used, should appear before the server
and fudge commands in the configuration file.
- The latest release of NTP4 includes support for tne nanokernel
precision time kernel support, which is now in stock Linux and FreeBSD
kernels. If a precision time source such as a GPS timing receiver or
cesium clock is available, kernel timekeeping can be improved to the
order less than one microsecond. The older precision time kernel for the
Alpha continues to be supported. The precision time support in stock
Solaris 2.6 has bugs that were fixed in 2.7. A patch is available that
fixes the 2.6 bugs. The 2.6 kernel discipline has been disabled by
default. For testing, the kernel can be enabled using the enable
kernel command either in the configuration file or via
ntpdc.
- A new pulse-per-second (PPS) generic interface described in Mogul, J., D. Mills, J.
Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like
operating systems, version 1. Request for Comments RFC-2783, Internet
Engineering Task Force, March 2000, 31 pp is supported. Older
interfaces and line disciplines continue to be supported, but may be
withdrawen in future versions.
- On Alpha 4.0 with reference clocks configured, debugging with the
-d options doesn't work.
- The latest release of NTPv4 includes support for autokey
public-key cryptography, which is the preferred scheme for
authenticating servers to clients. It uses NTP header extensions fields
documented in Mills, D.L. Public key
cryptography for the Network Time Protocol. Electrical Engineering
Report 00-5-1, University of Delaware, May 2000. 23 pp and
implemented in this release. However, the protocol is still evolving and
some fields may not conform to that document. The design provides for
orderly key refreshment and does not require public keys and related
media to be copied from one machine to another. Specific information
about autokey cryptography is contained in the Authentication Options page and links from
thnere.
- The manycast function still needs some work. Ideally, the
existing I/O routines would be enhanced to include the capability to
determine the source address on every multicast packet sent, so that the
autokey function could reliably construct the correct cryptosum.
Meanwhile, the utility of manycast in conjunction with autokey is
limited to clients with only a single network interface.
- The HTML documentation has been partially updated. However, most
of the NTPv3 documentation continues to apply to NTPv4. Until the update
happens, what you see is what you get. We are always happy to accept
comments, corrections and bug reports. However, we are most thrilled
upon receipt of patches to fix the dang bugs.
David L. Mills <mills@udel.edu>