aboutsummaryrefslogtreecommitdiff
path: root/contrib/ntp/html/release.htm
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/ntp/html/release.htm')
-rw-r--r--contrib/ntp/html/release.htm485
1 files changed, 288 insertions, 197 deletions
diff --git a/contrib/ntp/html/release.htm b/contrib/ntp/html/release.htm
index 8b29cb9f412a..9dcef7c2e636 100644
--- a/contrib/ntp/html/release.htm
+++ b/contrib/ntp/html/release.htm
@@ -1,199 +1,290 @@
-<HTML><HEAD><TITLE>
-NTP Version 4 Release Notes
-</TITLE></HEAD><BODY><H3>
-NTP Version 4 Release Notes
-</H3>
-
-<IMG align=left SRC=pic/hornraba.gif> <i>Alice's Adventures in
-Wonderland</i>, by Lewis Carroll, illustrations by Sir John Tenniel
-<BR clear=left><HR>
-
-<H4>NTP Version 4 Release Notes</H4>
-
-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 implemented in the current NTPv3. 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 NT, VMS and various reference clock drivers. As always,
-corrections and bugfixes are warmly received, especially in the form of
-context diffs.
-
-<P>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
-
-<OL>
-
-<P><LI>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.</LI>
-
-<P><LI>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.</LI>
-
-<P><LI>A <A HREF=assoc.htm>burst-mode</A> 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. Outlyers due to initial dial-up delays, etc., are avoided and the
-server synchronizes with its peer generally within 30 s.</LI>
-
-<P><LI>In addition to the NTPv3 authentication scheme, which uses
-private-key cryptography, a new NTPv4 <A HREF=authopt.htm>autokey
-</A>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.</LI>
-
-<P><LI>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 <A HREF=assoc.htm>multicast
-</A>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 <A HREF=assoc.htm>manycast </A>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
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>NTP Version 4 Release Notes</title>
+</head>
+<body>
+<h3>NTP Version 4 Release Notes</h3>
+
+<img align="left" src="pic/hornraba.gif" alt="gif"><a href=
+"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Alice's
+Adventures in Wonderland</i>, Lewis Carroll</a>
+
+<p>The rabbit toots to make sure you read this.<br clear="left">
+</p>
+
+<hr>
+<p>This document was last updated 4 May 2001</p>
+
+<h4>NTP Version 4 Release Notes</h4>
+
+<p>This release of the NTP Version 4 (NTPv4) daemon for Unix, VMS
+and Windows (NT4 and 2000) incorporates new features and
+refinements to the NTP Version 3 (NTPv3) algorithms. However, it
+continues the tradition of retaining backwards compatibility with
+older versions, except for symmetric mode in NTPv1. Client/server
+mode continues to be supported in NTPv1. 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.</p>
+
+<p>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.</p>
+
+<p>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. Additional information on protocol
+compatibility details is in the <a href="biblio.htm">Protocol
+Conformance Statement</a> page.</p>
+
+<ol>
+<li>
+<p>Most calculations are now done using 64-bit floating double
+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
+floating double. 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 floating
+double. The differences are ordinarily quite small so can be
+expressed without loss of accuracy in this format.</p>
+</li>
+
+<li>
+<p>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.</p>
+</li>
+
+<li>
+<p>This release includes support for the <a href=
+"http://www.eecis.udel.edu/~mills/resource.htm"><i>
+nanokernel</i></a> 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.</p>
+</li>
+
+<li>
+<p>This release 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. Internet Draft draft-ietf-stime-ntpauth-00.txt,
+University of Delaware, June 2000, 36 pp. <a href=
+"http://www.eecis.udel.edu/~mills/database/memos/draft-ietf-stime-ntpauth-00.txt">
+ASCII</a> and implemented in this release. 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 <a href=
+"authopt.htm">Authentication Options</a> page and links from
+there.</p>
+</li>
+
+<li>
+<p>NTPv4 includes two new association modes which in most
+applications can avoid per-host configuration altogether. Both of
+these are based on IP multicast technology and Autokey
+cryptography. They provide for automatic discovery and
+configuration of servers and clients without identifying servers or
+clients in advance. In multicast mode a server sends a message at
+fixed intervals using specified multicast group 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 to a specified
+multicast group address 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. The manycast scheme can provide
somewhat better accuracy than the multicast scheme at the price of
-additional network overhead.</LI>
-
-<P><LI>The reference clock driver interface is smaller, more rational
-and moreaccurate. 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. Drivers for the
-Canadian standard time and frequency station CHU and for audio IRIG
-signals have been updated and capabilites added to allow direct
-connection of these signals to the Sun audio port
-<TT>/dev/audio</TT>.</LI>
-
-<P><LI>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.</LI>
-
-<P><LI>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.</LI>
-
-<P><LI>The entire distribution has been converted to <TT>gnu
-automake</TT>, 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.</LI>
-</OL>
-
-<H4>Nasty Surprises</H4>
-
-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:
-
-<OL>
-
-<P><LI>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 distribtution. These routines are readily
-available in most countries from RSA Laboratories. Directions for their
-use are in the <A HREF=build.htm>Building and Installing the
-Distribution</A> page.</LI>
-
-<P><LI>As the result of the above, the <TT>./authstuff</TT> directory,
+additional network overhead. See the <a href="assoc.htm">
+Association Management</a> page for further information.</p>
+</li>
+
+<li>
+<p>There are two burst mode features available where special
+conditions apply. One of these is enabled by the <tt>iburst</tt>
+keyword in the <tt>server</tt> configuration command. It is
+intended for cases where it is important to set the clock quickly
+when an association is first mobilized. The other is enabled by the
+<tt>burst</tt> keyword in the <tt>server</tt> configuration
+command. It is intended for cases where the network attachment
+requires an initial calling or training procedure. See the <a href=
+"assoc.htm">Association Management</a> page for further
+information.</p>
+</li>
+
+<li>
+<p>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 39 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 <tt>/dev/audio</tt>.</p>
+</li>
+
+<li>
+<p>In all except a very few cases, all timing intervals are
+randomized, so that the tendency for NTPv3 to self-synchronize and
+bunch messages, especially with a large number of configured
+associations, is minimized.</p>
+</li>
+
+<li>
+<p>In NTPv3 a large number of weeds and useless code had grown over
+the years since the original NTPv1 code was implemented almost
+twenty years ago. Using a powerful weedwacker, much of the
+shrubbery has been removed, with effect a substantial reduction in
+size of almost 40 percent.</p>
+</li>
+
+<li>
+<p>The entire distribution has been converted to gnu <tt>
+automake</tt>, 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.</p>
+</li>
+</ol>
+
+<h4>Nasty Surprises</h4>
+
+<p>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:</p>
+
+<ol>
+<li>
+<p>As required by Defense Trade Regulations (DTR), the
+cryptographic routines supporting the Data Encryption Standard
+(DES) have been removed from the base distribution. These routines
+are readily available in most countries from RSA Laboratories.
+Directions for their use are in the <a href="build.htm">Building
+and Installing the Distribution</a> page.</p>
+</li>
+
+<li>
+<p>As the result of the above, the <tt>./authstuff</tt> 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
-<TT>rsaref2.0</TT> package available from RSA laboratories.</LI>
-
-<P><LI>The enable and disable commands have a few changes in their
-arguments see the <TT>ntpd</TT> <A HREF=confopt.htm>Configuration
-Options</A> page for details.</LI>
-
-<P><LI>The scheme for enabling the <TT>ppsclock</TT> line
-discipline/streams module has changed. Formerly, it was enabled by
-setting f<TT>udge flag3</TT> for the serial port connected to the PPS
-signal. Now, there is an explicit command <TT>pps</TT> used to designate
-the device name. See the <A HREF=clockopt.htm>Reference Clock
-Options</A> page for details.</LI>
-
-<P><LI>While in fact not a new problem, some obscure option combinations
-require the <TT>server</TT> and <TT>peer</TT> commands to follow the
-others; in particular, the <TT>enable</TT> and <TT>pps</TT> commands
-should preceed these commands.</LI>
-
-</OL>
-
-<H4>Caveats</H4>
-
-This release has been compiled and tested on several systems, including
-SunOS 4.1.3, Solaris 2.5.1 and 2.6, Alpha 4.0, Ultrix 4.4, Linux,
-FreeBSD and HP-UX 10.02. It has not been compiled for Windows NT or VMS.
-We are relying on the NTP volunteer brigade to do that. Known problems
-are summarized below:
-
-<OL>
-
-<P><LI>To work properly in all cases, the <TT>enable</TT> and
-<TT>pps</TT> commands, if used, should appear before the <TT>server</TT>
-and <TT>fudge</TT> commands in the configuration file.</LI>
-
-<P><LI>The precision time kernel modifications now in stock Solaris 2.6
-have bugs. The kernel discipline has been disabled by default. For
-testing, the kernel can be enabled using the <TT>enable kernel</TT>
-command either in the configuration file or via <TT>ntpdc</TT>.</LI>
-
-<P><LI>On Alpha 4.0 with reference clocks configured, debugging with the
-<TT>-d</TT> options doesn't work.</LI>
-
-<P><LI>The autokey function requires an NTP header extensions field,
-which is documented in an internet draft and implemented in this
-release. This field holds the public-key signature and certificate;
-however, the detailed format for these data have not yet been
-determined. It is expected this will happen in the near future and that
-implementation of the required algorithms will quickly follow using
-available cryptographic algorithms.</LI>
-
-<P><LI>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.</LI>
-
-<P><LI>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.</LI>
-
-</OL>
-
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
-</address></a></body></html>
+routines to exotic architectures, has been removed. Developers
+should note the NTP authentication routines use the interface
+defined in the <tt>rsaref2.0</tt> package available from RSA
+laboratories.</p>
+</li>
+
+<li>
+<p>The enable and disable commands have a few changes in their
+arguments see the <tt>ntpd</tt> <a href="confopt.htm">Configuration
+Options</a> page for details. Note that the <tt>authenticate</tt>
+command has been removed.</p>
+</li>
+
+<li>
+<p>The <tt>ppsclock</tt> line discipline/streams module is no
+longer supported. This function is now handled by the <a href=
+"driver22.htm">PPS Clock Discipline</a> driver, which uses the new
+PPSAPI application program interface proposed by the IETF. Note
+that the <tt>pps</tt> configuration file command has been obsoleted
+by the driver. See the <a href="pps.htm">Pulse-per-second (PPS)
+Signal Interfacing</a> page for further information.</p>
+</li>
+
+<li>
+<p>Several new options have been added for the <tt>ntpd</tt>
+command line. For the inveterate knob twiddlers several of the more
+important performance variables can be changed to fit actual or
+perceived special conditions. It is possible to operate the daemon
+in a one-time mode similar to <tt>ntpdate</tt>, which program is
+headed for retirement. See the <a href="ntpd.htm"><tt>ntpd</tt> -
+Network Time Protocol (NTP) daemon</a> page for the new
+features.</p>
+</li>
+
+<li>
+<p>To help reduce the level of spurious network traffic due to
+obsolete configuration files, a special control message called the
+kiss-of-death packet has been implemented. If enabled and a packet
+is denied service or exceeds the client limie, a compliant server
+will send this message to the client. A compliant client will cease
+further transmission and send a message to the system log. See the
+<a href="accopt.htm">Authentication Options</a> page for further
+information.</p>
+</li>
+
+<li>
+<p>An experimental filter algorithm called huff-n'-puff has been
+implemented to reduce errors under conditions of severe assymetric
+delays characteristic of <tt>ppp</tt> connections with telephone
+modems and downloading or uploading considerable traffic. See the
+<a href="ntpd.htm">ntpd - Network Time Protocol (NTP) daemon</a>
+page for further information.</p>
+</li>
+</ol>
+
+<h4>Caveats</h4>
+
+<p>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 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:</p>
+
+<ol>
+<li>
+<p>The latest NTPv4 <tt>ntpdc</tt> does not work with previous
+versions of <tt>ntpd</tt> and previous versions of <tt>ntpdc</tt>
+do not work with latest <tt>ntpd</tt>. 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.</p>
+</li>
+
+<li>
+<p>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 <tt>enable kernel</tt>
+command either in the configuration file or via <tt>ntpdc</tt>.</p>
+</li>
+
+<li>
+<p>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.</p>
+</li>
+</ol>
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+&lt;mills@udel.edu&gt;</a></address>
+</body>
+</html>
+