NTP Version 4 Release Notes

NTP Version 4 Release Notes

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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

1. 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.
2. 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.
3. The enable and disable commands have a few changes in their arguments see the ntpd Configuration Options page for details.
4. 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.
5. 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

1. 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.

2. 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.
3. 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.
4. 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.

5. On Alpha 4.0 with reference clocks configured, debugging with the -d options doesn't work.
6. 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.
7. 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.
8. 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.