diff options
Diffstat (limited to 'contrib/ntp/html/release.htm')
| -rw-r--r-- | contrib/ntp/html/release.htm | 485 |
1 files changed, 288 insertions, 197 deletions
diff --git a/contrib/ntp/html/release.htm b/contrib/ntp/html/release.htm index 8b29cb9..9dcef7c 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 <mills@udel.edu></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 +<mills@udel.edu></a></address> +</body> +</html> + |
