* include/ntp_crypto.h: Make sure crypto_flags is visible.
Many files:
* html/release.htm:
* html/patches.htm:
* html/measure.htm:
* html/confopt.htm:
* html/clockopt.htm:
* html/biblio.htm:
* html/authopt.htm:
* html/assoc.htm:
Updates from Dave Mills.
bk: 3a499b08Pxb8ZOmOzOwFOVudHI5rbg
+2000-12-27 Harlan Stenn <stenn@whimsy.udel.edu>
+
+ * html/release.htm:
+ * html/patches.htm:
+ * html/measure.htm:
+ * html/confopt.htm:
+ * html/clockopt.htm:
+ * html/biblio.htm:
+ * html/authopt.htm:
+ * html/assoc.htm:
+ Updates from Dave Mills.
+
+ * include/ntp_crypto.h: Make sure crypto_flags is visible.
+ From Dave Mills.
+
2000-12-14 Harlan Stenn <stenn@whimsy.udel.edu>
* ntpd/ntp_proto.c (process_packet): pleap/pstratum.
-<HTML><TITLE>
+<html><title>
Association Management
-</TITLE></HEAD><BODY><H3>
+</title></head><body><h3>
Association Management
-</H3><HR>
-
-<H4>Association Modes</H4>
-
-The NTP Version 4 incorporates new features and refinements to the NTP
-Version 3 (NTPv3) algorithms. However, it continues the tradition of
-retaining backwards compatibility with older versions. However, a number
-of new features have been implemented, including a number of new
-operating modes for automatic server discovery and improved accuracy in
-occasionally-connected networks. Following is an extended abstract
-describing the new features. Additional information is available on the
-<a href=confopt.htm>Configuration Options</a> page..
-
-<P>An ephemeral association of some mode is mobilized when a message
-arrives from a server or peer. For instance, a symmetric-passive
-association is mobilized upon arrival of a message from a symmetric-
-active peer. A client association is mobilized upon arrival of a
-broadcast message from a multicast server or a server message from a
-manycast server. Ordinarily, successful mobilization requires the server
-or peer provide acceptable cryptographic credentials, either using
-traditional symmetric-key cryptography or public-key cryptography new to
-NTPv4. Ephemeral associations are demobilized when either (a) the server
-becomes unreachable or (b) the server refreshes key media without
-notifying the client.
-
-<P>Following is a summary of the protocol operations for each mode.
-
-<P>Symmetric Modes (Active and Passive)
-
-<UL>In these modes, two client/server peers agree to back each other up,
-should the synchronization source for either peer fail. One or both
-peers is configured in symmetric-active mode using the <tt>peer</tt>
-command. Alternatively, one - the active peer - is configured in this
-mode and the other, the passive peer, operates in symmetric-passive mode
-and requires no prior configuration. Both association scenarios operate
-in NTPv4 as in NTPv3; however, several bugs in the handling of keys and
-recovery of resources when an active peer fails have been corrected in
-NTPv4. The original NTPv3 authentication scheme is applicable in this
-mode, as well as the new NTPv3 autokey scheme.</UL>
-
-Client/Server Modes
-
-<UL>In these modes, a client sends a request to the server and expects a
-reply at some future time. The client is configured in client mode using
-the <tt>server</tt> (sic) command; the server requires no prior
-configuration. The original NTPv3 authentication scheme is applicable in
-this mode, as well as the new NTPv3 autokey scheme. In addition, the
-burst modes described below can be used in appropriate cases.</UL>
-
-Broadcast/Multicast Modes
-
-<UL>In these modes, the server generates messages at intervals specified
-by the <tt>minpoll</tt> keyword to the configuration command. When using
-IP multicast addresses, the scope of the multicast tree is specified by
-the <tt>ttl</tt> keyword in hops. When using a local interface broadcast
-address, the scope is limited to the attached subnet. The client
-responds to the first message received by waiting an interval randomized
-over the <tt>minpoll</tt> interval, in order to avoid implosions. Then,
-it polls the server in burst mode in order to accumulate data to
-reliably set the host clock. This normally results in eight
-client/server cycles over a 30-s interval. When the next multicast
-message is received, the client computes the offset between the system
-clock just set and the apparent time of the multicast message in order
-to correct the apparent time in future multicast messages.</UL>
-
-Manycast Mode
-
-<UL>In this mode, a configured client broadcasts a request message as in
-client mode to a designated multicast group address. All servers
-configured as manycast servers and in <tt>ttl</tt> range respond with a
-server reply message. Each reply mobilizes a persistent client/server
-association as in client mode. Then, the NTP intersection and clustering
-algorithms act to discard all but the "best" of these associations,
-which then continue as in client/server mode.
-
-<p>The above scenario happens at each manycast message; however, once
-the persisten association has been mobilized, subsequent server replies
-are discarded, since they fail one or more of the authentication checks.
-It is important in manycast mode to avoid frequeny request messages,
-since each one requires all manycast servers in range to respond. The
-result could well be an implosion, either minor or major, depending on
-the number of servers in range.</UL>
-
-<H4>Burst Modes</H4>
-
-<p>There are two burst modes that can be activated for client/server
-mode. One of these <tt>iburst</tt> is intended for cases where it is
-important to set the clock quickly when an association is first
-mobilized. It results in good accuracy with intermittent connections
-typical of PPP and ISDN services. When enabled, at each poll interval
-the client sends eight messages over the next 30-s 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 client sets the
-clock within 30 s after the first message.</LI>
-
-<p>The other burst mode <tt>burst</tt> can be configured when the
-network attachment requires an initial calling or training procedure.
-Each poll initiates a burst of eight request messages at intervals
-randomized over the range 3-5 s. The reply messages update the clock
-filter, which then selects the best (most accurate) among them. When the
-last reply in the burst is sent, the next reply updates the client
-variables and system clock in the usual manner, as if only a single
-request/reply cycle had occurred. This mode does produce additional
-network overhead and can cause trouble if used indiscriminately. It
-should only be used where the poll interval is expected to settle to
-values above 1024 s.
-
-
-<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>
+</h3><hr>
+
+<h4>Association Modes</h4>
+
+<p>NTP Version 4 (NTPv4) incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms; however, it continues the tradition of backwards compatibility with older versions. A number of new operating modes for automatic server discovery and improved accuracy in occasionally connected networks are provided. Following is an overview of the new features; additional information is available on the <a href=confopt.htm>Configuration Options</a> and <a href=authopt.htm>Authentication Options</a> pages and in the papers, reports, memoranda and briefings at www.ntp.org.
+
+<p>There are two types of associations: persistent associations, which result from configuration file commands, and ephemeral associations, which result from protocol operations described below. A persistent association is never demobilized, although it may become dormant when the associated server becomes unreachable. An ephemeral association is mobilized when a message arrives from a server; for instance, a symmetric passive association is mobilized upon arrival of a symmetric active message. A broadcast client association is mobilized upon arrival of a broadcast server message, while a manycast client association is mobilized upon arrival of a manycast server message.
+
+<p>Ordinarily, successful mobilization of an ephemeral association requires the server to be cryptographically authenticated to the dependent client. This can be done using either symmetric-key or public-key cryptography, as described in the <a href=authopt.htm>Authentication Options</a> page. The cryptographic means insure an unbroken chain of trust between the dependent client and the primary servers at the root of the synchronization subnet. We call this chain the provenance of the client and define new vocabulary as to proventicate a client or provide proventic credentials. Once mobilized, ephemeral associations are demobilized when either (a) the server becomes unreachable or (b) the server refreshes the key media without notifying the client.
+
+<p>There are three principal modes of operation: client/server, symmetric active/passive and broadcast. In addition, there are two modes using IP Multicast support: multicast and manycast. These modes are selected based on the scope of service, intended flow of time and proventic values and means of configuration. Following is a summary of the operations in each mode.
+
+<h4>Client/Server Mode</h4>
+
+<p>Client/server mode is probably the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers. In this mode a client sends a request to the server and expects a reply at some future time. In some contexts this would be described as a "pull" operation, in that the client pulls the time and proventic values from the server. A client is configured in client mode using the <tt>server</tt> (sic) command and specifying the server DNS name or address; the server requires no prior configuration. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme. In addition, two burst modes described below can be used in appropriate cases.
+
+<h4>Symmetric Active/Passive Mode</h4>
+
+<p>Symmetric active/passive mode is intended for configurations were a clique of low-stratum peers operate as mutual backups for each other. Each peer operates with one or more primary reference sources, such as a radio clock, or a subset of secondary servers known to be reliable and proventicated. Should one of the peers lose all reference sources or simply cease operation, the other peers will automatically reconfigure so that time and proventication values can flow from the surviving peers to all the others in the clique. In some contexts this would be described as a "push-pull" operation, in that the peer either pulls or pushes the time and proventic values depending on the particular configuration.
+
+<p>Symmetric peers operate with their sources in some NTP mode and with each other in symmetric mode. A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer DNS name or address. The other peer can also be configured in symmetric active mode in a similar way. However, if the other peer is not specifically configured in this way, a symmetric passive association is mobilized upon arrival of a symmetric active message. Since an intruder can impersonate a symmetric active peer and inject false time values, symmetric mode should always be cryptographically validated. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme.
+
+<h4>Broadcast Mode</h4>
+
+<p>Broadcast mode is intended for configurations involving one or a few servers and a possibly very large client population. A broadcast server is configured using the <tt>broadcast</tt> command and a local subnet address. A broadcast client is configured using the <tt>broadcastclient</tt> command, in which case it responds to broadcast messages received on any interface. Since an intruder can impersonate a broadcast server and inject false time values, this mode should always be cryptographically validated. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme.
+
+<p>The server generates broadcast messages continuously at intervals specified by the <tt>minpoll</tt> keyword and with a time-to-live span specified by the <tt>ttl</tt> keyword. A NTPv4 broadcast client responds to the first proventicated message received by waiting an interval randomized over the <tt>minpoll</tt> interval, in order to avoid implosion at the server. Then, the client polls the server in burst mode in order to reliably set the host clock and validate the source. This normally results in a volley of eight client/server cycles over a 30-s interval during which both the synchronization and cryptographic protocols run concurrently. When the next broadcast message is received after the volley, the client computes the offset between the apparent broadcast time and the (unicast) client time. This offset is used to compensate for the propagation time between the broadcast server and client. Once the offset is computed, the server continues as before and the client sends no further messages.
+
+<h4>IP Multicast Support</h4>
+
+<p>Broadcast mode in both NTPv3 and NTPv4 is limited to directly connected subnets such as Ethernets which support broadcast technology. Ordinarily, this technology does not operate beyond the first hop router or gateway. Where service is intended beyond the local subnet, IP multicasting can be used where supported by the operating system and the routers support the Internet Group Management Protocol (IGMP). Most current kernels and available routers do support IP multicast technology, although service providers are sometimes reluctant to deploy it.
+
+<p>A general discussion of IP multicast technology is beyond the scope here. In simple terms a host or router sending to a IP multicast group (class D) address expects all hosts or routers listening on this address to receive the message. There is no intrinsic limit on the number of senders or receivers and senders can be receivers and vice versa. The IANA has assigned multicast group address 224.0.1.1 to NTP, but this address should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped group addresses should be used as described in RFC-2365.
+
+<h4>Multicasting</h4>
+
+<p>IP multicasting can be used to extend the scope of a timekeeping subnet in two ways: multicasting and manycasting. A multicast client is configured using the <tt>broadcast</tt> command, but with a multicast group (class D) address instead of a local subnet broadcast address. However, there is a subtle difference between broadcasting and multicasting. Broadcasting is specific to each interface and local subnet address. If more than one interface is attached to a machine, a separate <tt>broadcast</tt> command applies to each one separately. This provides a way to limit exposure in a firewall, for example.
+
+<p>IP multicasting is a different paradigm. A multicast message has the same format as a broadcast message and is configured with the same <tt>broadcast</tt> command, but with a multicast group address instead of a local subnet address. By design, multicast messages travel from the sender via a shortest-path or shared tree to the receivers, which may require these messages emit from one or all interfaces, but carry a common source address. However, it is possible to configure multiple multicast group addresses using multiple <tt>broadcast</tt> commands. Other than these particulars, multicast messages are processed just like broadcast messages. Note that the calibration feature in broadcast mode is extremely important, since IP multicast messages can travel far different paths through the IP routing fabric than ordinary IP unicast messages.
+
+<h4>Manycasting</h4>
+
+<p>Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a multicast client to troll the nearby network neighborhood to find cooperating manycast servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each manycast client mobilizes client associations with the "best" three of the available manycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail.
+
+<p>Note that the manycasting paradigm does not coincide with the anycasting paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycasting paradigm is designed to find a plurality of redundant servers, in this case willing NTP servers.
+
+<p>A persistent manycast client association is configured using the <tt>server</tt> command, but with a multicast (class D) group address instead of an ordinary IP (class A, B, C) address. It sends client mode messages to this address at the maximum feasible poll interval and minimum feasible time-to-live hops, depending on how many servers have already been found. There can be as many manycast client associations as different group addresss, each one serving as a template for a future ephemeral client/server mode association.
+
+<p>Manycast servers configured with the <tt>manycastserver</tt> command listen on the specified group address for manycast client messages. Note the distinction between manycast client, which is configured with a <tt>server</tt> command, and manycast server, which is configured with a <tt>manycastserver</tt> command. If a manycast server is in range of the current time-to-live and is itself synchronized to a valid source and operating at a stratum level equal to or lower than the manycast client, it replies to the manycast client message with an ordinary server mode message.
+
+<p>The manycast client receiving this message mobilizes an ephemeral client association as in ordinary client/server mode according to the matching manycast client template. Then, the client polls the server at its unicast address in burst mode in order to reliably set the host clock and validate the source. This normally results in a volley of eight client/server cycles over a 30-s interval during which both the synchronization and cryptographic protocols run concurrently. Following the volley, the client runs the NTP intersection and clustering algorithms, which act to discard all but the best three associations. The surviving associations then continue in ordinary client/server mode.
+
+<p>The manycast client polling program is designed to reduce as much as possible the volume of messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. The program starts with the poll interval specified by the <tt>minpoll</tt> keyword and a time-to-live of one hop. At each transmission the time-to-live is incremented by one until at least three manycast servers are found, at which point the poll interval is clamped at the value specified by the <tt>maxpoll</tt> keyword. Further transmissions use the same poll interval and time-to-live values.
+
+<p>If less than three servers are found when the time-to-live has reached the maximum specified by the <tt>ttl</tt> keyword, the poll interval is doubled. For each transmission after that, the poll interval is doubled again until reaching the maximum specified by the <tt>maxpoll</tt> keyword. Further transmissions use the same poll interval and time-to-live values.
+
+<p>The above scenario happens for each manycast client message, which repeats at the designated poll interval. However, once the ephemeral client association is mobilized, subsequent manycast server replies are discarded, since they will fail the message digest test. If during a poll interval the number of client associations falls below three, all manycast client prototype associations are reset to the initial poll interval and time-to-live values and operation resumes from the beginning. It is important in manycast mode to avoid frequent manycast client messages, since each one requires all manycast servers in range to respond. The result could well be an implosion, either minor or major, depending on the number of servers in range. The recommended value for <tt>maxpoll</tt> is 12 (4,096 s) and for <tt>ttl</tt> is 7.
+
+<p>It is possible and frequently useful to configure a host as both a manycast client and manycast server. A number of hosts configured this way and sharing a common group address will automatically organize themselves in an optimum configuration based on the smallest synchronization distance computed by the NTP mitigation algorithms. For example, consider an NTP subnet of two primary servers and maybe a dozen dependent clients. All servers and clients are configured as both multicast client and multicast server with multicast group address 239.1.1.1. In addition, the primary servers are configured for a primary reference source such as a GPS receiver.
+
+Once operations have stabilized in this scenario, the primary servers will affiliate with the primary reference source and each other, since they both operate at the same stratum (1), but not with any client, since clients operate at a higher stratum. The clients will find both primary servers and in addition, one of their own at the minimum synchronization distance. If one of the primary servers loses its GPS receiver, it will continue to operate as a client and other clients will time out the corresponding association and re-associate accordingly.
+
+<h4>Burst Modes</h4>
+
+<p>There are two burst modes that can be enabled in client/server mode using the <tt>iburst</tt> and <tt>burst</tt> keywords. In either mode a single poll initiates a burst of eight client messages at intervals randomized over the range 1-4 s. However, the interval between the first and second messages is increased to about 16 s in order for a dialup modem to complete a call, if necessary. Received server messages update the NTPv4 clock filter, which selects the best (most accurate) time values. When the last client message in the burst is sent, the next received server message updates the system variables and sets the system clock in the usual manner, as if only a single client/server cycle had occurred. The result is not only a rapid and reliable setting of the system clock, but a considerable reduction in network jitter.
+
+<p>The <tt>iburst</tt> keyword can be configured for cases where it is important to set the clock quickly when an association is first mobilized or first becomes reachable or when the network attachment requires an initial calling or training procedure. The burst is initiated only when the server first becomes reachable and results in good accuracy with intermittent connections typical of PPP and ISDN services. Outlyers due to initial dial-up delays, etc., are avoided and the client sets the clock within 30 s after the first message.
+
+<p>The <tt>burst</tt> keyword can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training procedure. The burst is initiated at each poll interval when the server is reachable. The burst does produce additional network overhead and can cause trouble if used indiscriminately. It should only be used where the poll interval is expected to settle to values at or above 1024 s.
+
+<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>
<h4>Authentication Support</h4>
-<p>Authentication support allows the NTP client to verify that the
-server is in fact known and trusted and not an intruder intending
-accidentally or on purpose to masquerade as that server. The NTPv3
-specification RFC-1305 defines an scheme which provides cryptographic
-authentication of received NTP packets. Originally, this was done using
-the Data Encryption Standard (DES) algorithm operating in Cipher Block
-Chaining (CBC) mode, commonly called DES-CBC. Subsequently, this was
-augmented by the RSA Message Digest 5 (MD5) algorithm using a private
-key, commonly called keyed-MD5. Either algorithm computes a message
-digest, or one-way hash, which can be used to verify the server has the
-correct private key and key identifier.
-
-<p>NTPv4 retains the NTPv3 schemes, properly described as symmetric-key
-cryptography and, in addition, provides a new <i>autokey</i> scheme
-based on public-key cryptography. Public-key cryptography is generally
-considered more secure than symmetric-key cryptography, since the
-security is based on a private value which is generated by each server
-and never revealed. With autokey all key distribution and management
-functions involve only public values, which considerably simplifies key
-distribution and storage.
-
-<p>Authentication is configured separately for each association using
-the <tt>key</tt> or autokey subcommands on the <tt>peer</tt>,
-<tt>server</tt>, <tt>broadcast</tt> and <tt>manycastclient</tt> commands
-as described in the <a href=config.htm>Configuration Options</a> page.
-The authentication options described below specify the suite of keys,
-select the key for each configured association and manage the
-configuration operations.
-
-<p>The <tt>auth</tt> flag controls whether new associations or remote
-configuration commands require cryptographic authentication. This flag
-can be set or reset by the <tt>enable</tt> and <tt>disable</tt>
-configuration commands and also by remote configuration commands sent by
-a <tt>ntpdc</tt> program running in another machine. If this flag is
-enabled, which is the default case, new broadcast client and symmetric
-passive associations and remote configuration commands must be
-cryptographically authenticated using either symmetric-key or public-key
-schemes. If this flag is disabled, these operations are effective even
-if not cryptographic authenticated. It should be understood that
-operating in the latter mode invites a significant vulnerability where a
-rogue hacker can seriously disrupt client timekeeping.
-
-<p>In networks with firewalls and large numbers of broadcast clients it
-may be acceptable to disable authentication, since that avoids key
-distribution and simplifies network maintenance. However, when the
-configuration file contains host names, or when a server or client is
-configured remotely, host names are resolved using the DNS and a
-separate name resolution process. In order to protect against bogus name
-server messages, name resolution messages are authenticated using an
-internally generated key which is normally invisible to the user.
-However, if cryptographic support is disabled, the name resolution
-process will fail. This can be avoided either by specifying IP addresses
-instead of host names, which is generally inadvisable, or by enabling
-the flag for name resolution and disabled it once the name resolution
-process is complete.
-
-<p>In addition to the default symmetric-key cryptographic support,
-support for public-key cryptography is available if the requisite
-<tt>rsaref20</tt> software distribution has been installed before
-building the distribution. Public-key cryptography provides secure
-authentication of servers without compromising accuracy and stability.
-The security model and protocol schemes for both symmetric-key and
-public-key cryptography are described below.
+<p>Authentication support allows the NTP client to verify that the server is in fact known and trusted and not an intruder intending accidentally or on purpose to masquerade as that server. The NTPv3 specification RFC-1305 defines an scheme which provides cryptographic authentication of received NTP packets. Originally, this was done using the Data Encryption Standard (DES) algorithm operating in Cipher Block Chaining (CBC) mode, commonly called DES-CBC. Subsequently, this was augmented by the RSA Message Digest 5 (MD5) algorithm using a private key, commonly called keyed-MD5. Either algorithm computes a message digest, or one-way hash, which can be used to verify the server has the correct private key and key identifier.
+
+<p>NTPv4 retains the NTPv3 schemes, properly described as symmetric-key cryptography and, in addition, provides a new Autokey scheme based on public-key cryptography. Public-key cryptography is generally considered more secure than symmetric-key cryptography, since the security is based on a private value which is generated by each server and never revealed. With Autokey all key distribution and management functions involve only public values, which considerably simplifies key distribution and storage.
+
+<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> subcommands on the <tt>peer</tt>, <tt>server</tt>, <tt>broadcast</tt> and <tt>manycastclient</tt> commands as described in the <a href=config.htm>Configuration Options</a> page. The authentication options described below specify the suite of keys, select the key for each configured association and manage the configuration operations.
+
+<p>The <tt>auth</tt> flag controls whether new associations or remote configuration commands require cryptographic authentication. This flag can be set or reset by the <tt>enable</tt> and <tt>disable</tt> configuration commands and also by remote configuration commands sent by a <tt>ntpdc</tt> program running in another machine. If this flag is enabled, which is the default case, new broadcast client and symmetric passive associations and remote configuration commands must be cryptographically authenticated using either symmetric-key or public-key schemes. If this flag is disabled, these operations are effective even if not cryptographic authenticated. It should be understood that operating in the latter mode invites a significant vulnerability where a rogue hacker can seriously disrupt client timekeeping.
+
+<p>In networks with firewalls and large numbers of broadcast clients it may be acceptable to disable authentication, since that avoids key distribution and simplifies network maintenance. However, when the configuration file contains host names, or when a server or client is configured remotely, host names are resolved using the DNS and a
+separate name resolution process. In order to protect against bogus name server messages, name resolution messages are authenticated using an internally generated key which is normally invisible to the user. However, if cryptographic support is disabled, the name resolution process will fail. This can be avoided either by specifying IP addresses instead of host names, which is generally inadvisable, or by enabling the flag for name resolution and disabled it once the name resolution process is complete.
+
+<p>An attractive alternative where multicast support is available is manycast mode, in which clients periodically troll for servers. Cryptographic authentication in this mode uses public-key schemes as described below. The principle advantage of this manycast mode is that potential servers need not be configured in advance, since the client finds them during regular operation, and the configuration files for all clients can be identical.
+
+<p>In addition to the default symmetric-key cryptographic support, support for public-key cryptography is available if the requisite <tt>rsaref20</tt> software distribution has been installed before building the distribution. Public-key cryptography provides secure authentication of servers without compromising accuracy and stability. The security model and protocol schemes for both symmetric-key and public-key cryptography are described below.
<h4>Symmetric-Key Scheme</h4>
-The original RFC-1305 specification allows any one of possibly 65,534
-keys, each distinguished by a 32-bit key identifier, to authenticate an
-association. The servers involved must agree on the key and key
-identifier to authenticate their messages. Keys and related information
-are specified in a key file, usually called <tt>ntp.keys</tt>, which
-should be exchanged and stored using secure procedures beyond the scope
-of the NTP protocol itself. Besides the keys used for ordinary NTP
-associations, additional keys can be used as passwords for the <tt><a
-href=ntpq.htm>ntpq</a></tt> and <tt><a href=ntpdc.htm>ntpdc</a></tt>
-utility programs.
-
-<p>When <tt>ntpd</tt> is first started, it reads the key file specified
-int he <tt>keys</tt> command and installs the keys in the key cache.
-However, the keys must be activated with the <tt>trusted</tt> command
-before use. This allows, for instance, the installation of possibly
-several batches of keys and then activating or deactivating each batch
-remotely using <tt>ntpdc</tt>. This also provides a revocation
-capability that can be used if a key becomes compromised. The
-<tt>requestkey</tt> command selects the key used as the password for the
-<tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects
-the key used as the password for the <tt>ntpq</tt> utility.
+The original RFC-1305 specification allows any one of possibly 65,534 keys, each distinguished by a 32-bit key identifier, to authenticate an association. The servers and clients involved must agree on the key and key identifier to authenticate their messages. Keys and related information are specified in a key file, usually called <tt>ntp.keys</tt>, which should be exchanged and stored using secure procedures beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href=ntpq.htm>ntpq</a></tt> and <tt><a href=ntpdc.htm>ntpdc</a></tt> utility programs.
+
+<p>When <tt>ntpd</tt> is first started, it reads the key file specified int he <tt>keys</tt> command and installs the keys in the key cache. However, the keys must be activated with the <tt>trusted</tt> command before use. This allows, for instance, the installation of possibly several batches of keys and then activating or deactivating each batch remotely using <tt>ntpdc</tt>. This also provides a revocation capability that can be used if a key becomes compromised. The <tt>requestkey</tt> command selects the key used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key used as the password for the <tt>ntpq</tt> utility.
<h4>Public-Key Scheme</h4>
-The original NTPv3 authentication scheme described in RFC-1305 continues
-to be supported; however, in NTPv4 an additional authentication scheme
-called <i>autokey</i> is available. It uses MD5 message digest, RSA
-public-key signature and Diffie-Hellman key agreement algorithms
-available from several sources, but not included in the NTPv4 software
-distribution. In order to be effective, the <tt>rsaref20</tt> package
-must be installed as described in the <tt>README.rsa</tt> file. Once
-installed, the configure and build process automatically detects it and
-compiles the routines required.
-
-The autokey scheme has several modes of operation corresponding to the
-various NTP modes supported. RSA signatures with timestamps are used in
-all modes to verify the source of cryptographic values. All modes use a
-special cookie which can be computed independently by the client and
-server. In symmetric modes the cookie is constructed using the
-Diffie-Hellman key agreement algorithm. In other modes the cookie is
-constructed from the IP addresses and a private value known only to the
-server. All modes use in addition a variant of the S-KEY scheme, in
-which a pseudo-random key list is generated and used in reverse order.
-These schemes are described along with an executive summary, current
-status, briefing slides and reading list, on the <a
-href=http://www.eecis.udel.edu/~mills/autokey.htm>Autonomous
-Authentication</a> page.
-
-<p>The cryptographic values used by the autokey scheme are incorporated
-as a set of files generated by the <a
-href=genkeys.htm><tt>ntp_genkeys</tt></a> program, including the
-symmetric private keys, public/private key pair, and the agreement
-parameters. See the <tt>ntp_genkeys</tt> page for a description of the
-formats of these files. They contain cryptographic values generated by
-the algorithms of the <tt>rsaref20</tt> package and are in printable
-ASCII format. All file names include the timestamp, in NTP seconds,
-following the default names given below. Since the file data are derived
-from random values seeded by the system clock and the file name includes
-the timestamp, every generation produces a different file and different
-file name.
-
-<p>The <tt>ntp.keys</tt> file contains the DES/MD5 private keys. It must
-be distributed by secure means to other servers and clients sharing the
-same security compartment and made visible only to root. While this file
-is not used with the autokey scheme, it is needed to authenticate some
-remote configuration commands used by the <a
-href=ntpdc.htm><tt>ntpq</tt></a> and <a href=ntpq.htm><tt>ntpdc</tt></a>
-utilities. The <tt>ntpkey</tt> file contains the RSA private key. It is
-useful only to the machine that generated it and never shared with any
-other daemon or application program, so must be made visible only to
-root.
-
-<p>The <tt>ntp_dh</tt> file contains the agreement parameters. It is
-necessary that all servers and clients of a security compartment share a
-single set of parameters, but it does not matter which <tt>ntp_dh</tt>
-file generates them. Servers load the parameters directly from the
-file, while the clients can load them indirectly from the servers using
-the autokey protocol. Note that the parameters will be requested by all
-associations, either configured or not; but, none of the associations
-can proceed until one of them has received them. Once loaded, the
-parameters can be provided on request to other clients and servers. The
-<tt>ntp_dh</tt> file can be also be distributed using insecure means,
-since the data are public values.
-
-<p>The <tt>ntpkey_<i>host</i></tt> file contains the RSA public key,
-where <tt><i>host</i></tt> is the name of the host. Each <tt>server</tt>
-or <tt>peer</tt> association requires the public key associated with the
-particular server or peer to be loaded either directly from the file or
-indirectly from the server using the autokey protocol. In addition,
-public keys are required for all configured associations, including
-those that might be mobilized by multicast servers or symmetric peers.
-These files can be widely distributed and stored using insecure means,
-since the data are public values.
-
-<p>Due to the widespread use of interface-specific naming, the host
-names used in configured and mobilized associations are determined by
-the Unix <tt>gethostname()</tt> library routine. Both the
-<tt>ntp_genkeys</tt> program and the autokey protocol derive the name of
-the public key file using the name returned by this routine. While every
-server and client is required to load their own public and private keys,
-the public keys for each client or peer association can be obtained from
-the server or peer using the autokey protocol. Note however, that at the
-current stage of development the authenticity of the server or peer and
-the cryptographic binding of the server name, address and public key is
-not yet established by a certificate authority or web of trust.
-Therefore, when the most secure requirements apply, the public keys and
-agreement parameters should be loaded from files, rather than using the
-autokey protocol.
+The original NTPv3 authentication scheme described in RFC-1305 continues to be supported; however, in NTPv4 an additional authentication scheme called Autokey is available. It uses MD5 message digest, RSA public-key signature and Diffie-Hellman key agreement algorithms available from several sources, but not included in the NTPv4 software distribution. In order to be effective, the <tt>rsaref20</tt> package must be installed as described in the <tt>README.rsa</tt> file. Once installed, the configure and build process automatically detects it and compiles the routines required.
+
+The Autokey scheme has several modes of operation corresponding to the various NTP modes supported. RSA signatures with timestamps are used in all modes to verify the source of cryptographic values. All modes use a special cookie which can be computed independently by the client and server. In symmetric modes the cookie is constructed using the Diffie-Hellman key agreement algorithm. In other modes the cookie is constructed from the IP addresses and a private value known only to the server. All modes use in addition a variant of the S-KEY scheme, in which a pseudo-random key list is generated and used in reverse order. These schemes are described along with an executive summary, current status, briefing slides and reading list, on the <a href=http://www.eecis.udel.edu/~mills/autokey.htm>Autonomous Authentication</a> page.
+
+<p>The cryptographic values used by the Autokey scheme are incorporated as a set of files generated by the <a href=genkeys.htm><tt>ntp-genkeys</tt></a> program, including the symmetric private keys, public/private key pair, and the agreement parameters. See the <tt>ntp-genkeys</tt> page for a description of the formats of these files. They contain cryptographic values generated by the algorithms of the <tt>rsaref20</tt> package and are in printable ASCII format. All file names include the timestamp, in NTP seconds, following the default names given below. Since the file data are derived from random values seeded by the system clock and the file name includes the timestamp, every generation produces a different file and different file name.
+
+<p>The <tt>ntp.keys</tt> file contains the DES/MD5 private keys. It must be distributed by secure means to other servers and clients sharing the same security compartment and made visible only to root. While this file is not used with the Autokey scheme, it is needed to authenticate some remote configuration commands used by the <a href=ntpdc.htm><tt>ntpq</tt></a> and <a href=ntpq.htm><tt>ntpdc</tt></a> utilities. The <tt>ntpkey</tt> file contains the RSA private key. It is useful only to the machine that generated it and never shared with any other daemon or application program, so must be made visible only to root.
+
+<p>The <tt>ntp_dh</tt> file contains the agreement parameters. It is necessary that all servers and clients of a security compartment share a single set of parameters, but it does not matter which <tt>ntp_dh</tt> file generates them. Servers load the parameters directly from the file, while the clients can load them indirectly from the servers using the Autokey protocol. Note that the parameters will be requested by all associations, either configured or not; but, none of the associations can proceed until one of them has received them. Once loaded, the parameters can be provided on request to other clients and servers. The <tt>ntp_dh</tt> file can be also be distributed using insecure means, since the data are public values.
+
+<p>The <tt>ntpkey_<i>host</i></tt> file contains the RSA public key, where <tt><i>host</i></tt> is the name of the host. Each <tt>server</tt> or <tt>peer</tt> association requires the public key associated with the particular server or peer to be loaded either directly from the file or indirectly from the server using the Autokey protocol. In addition, public keys are required for all configured associations, including those that might be mobilized by multicast servers or symmetric peers. These files can be widely distributed and stored using insecure means, since the data are public values.
+
+<p>Due to the widespread use of interface-specific naming, the host names used in configured and mobilized associations are determined by the Unix <tt>gethostname()</tt> library routine. Both the <tt>ntp-genkeys</tt> program and the Autokey protocol derive the name of the public key file using the name returned by this routine. While every server and client is required to load their own public and private keys, the public keys for each client or peer association can be obtained from the server or peer using the Autokey protocol. Note however, that at the current stage of development the authenticity of the server or peer and the cryptographic binding of the server name, address and public key is not yet established by a certificate authority or web of trust. Therefore, when the most secure requirements apply, the public keys and agreement parameters should be loaded from files, rather than using the Autokey protocol.
<h4>Leapseconds Table</tt>
-<p>The NIST provides a table showing the epoch for all historic
-occasions of leap second insertion since 1972. The leapsecond table
-shows each epoch of insertion along with the offset of International
-Atomic Time (TAI) with respect to Coordinated Universtal Time (UTC), as
-disseminated by NTP. The table can be obtained directly from NIST
-national time servers using <tt>ftp</tt> as the ASCII file <tt>pub/leap-
-seconds</tt>.
-
-<p>While not strictly a security function, the Autokey scheme provides
-means to securely retrieve the leapsecond table from a server or peer.
-Servers load the leapsecond table directly from the file specified in
-the <tt>crypto</tt> command, while clients can load the table indirectly
-from the servers using the autokey protocol. Note that the table will be
-requested by all associations, either configured or not; but, none of
-the associations can proceed until one of them has received the table.
-Once loaded, the table can be provided on request to other clients and
-servers.
+<p>The NIST provides a table showing the epoch for all historic occasions of leap second insertion since 1972. The leapsecond table shows each epoch of insertion along with the offset of International Atomic Time (TAI) with respect to Coordinated Universtal Time (UTC), as disseminated by NTP. The table can be obtained directly from NIST national time servers using <tt>ftp</tt> as the ASCII file <tt>pub/leap-seconds</tt>.
+
+<p>While not strictly a security function, the Autokey scheme provides means to securely retrieve the leapsecond table from a server or peer. Servers load the leapsecond table directly from the file specified in the <tt>crypto</tt> command, while clients can load the table indirectly from the servers using the Autokey protocol. Once loaded, the table can be provided on request to other clients and servers.
<h4>Key Management</h4>
-<p>All key files are installed by default in <tt>/usr/local/etc</tt>,
-which is normally in a shared filesystem in NFS-mounted networks and
-avoids installing them in each machine separately. The default can be
-overridden by the <tt>keysdir</tt> configuration command. However, this
-is not a good place to install the private key file, since each machine
-needs its own file. A suitable place to install it is in <tt>/etc</tt>,
-which is normally not in a shared filesystem.
-
-<p>The recommended practice is to keep the timestamp extensions when
-installing a file and to install a link from the default name (without
-the timestamp extension) to the actual file. This allows new file
-generations to be activated simply by changing the link. However,
-<tt>ntpd</tt> parses the link name when present to extract the extension
-value and sends it along with the public key and host name when
-requested. This allows clients to verify that the file and generation
-time are always current. However, the actual location of each file can
-be overridden by the <tt>crypto</tt> configuration command.
-
-<p>All cryptographic keys and related parameters should be regenerated
-on a periodic and automatic basis, like once per month. The
-<tt>ntp_genkeys</tt> program uses the same timestamp extension for all
-files generated at one time, so each generation is distinct and can be
-readily recognized in monitoring data. While a public/private key pair
-must be generated by every server and client, the public keys and
-agreement parameters do not need to be explicitly copied to all machines
-in the same security compartment, since they can be obtained
-automatically using the autokey protocol. However, it is necessary that
-all primary servers have the same agreement parameter file. The
-recommended way to do this is for one of the primary servers to generate
-that file and then copy it to the other primary servers in the same
-compartment using the Unix <tt>rdist</tt> command. Future versions of
-the autokey protocol are to contain provisions for an agreement protocol
-to do this automatically.
-
-<p>Servers and clients can make a new generation in the following way.
-All machines have loaded the old generation at startup and are operating
-normally. At designated intervals, each machine generates a new
-public/private key pair and makes links from the default file names to
-the new file names. The <tt>ntpd</tt> is then restarted and loads the
-new generation, with result clients no longer can authenticate
-correctly. The autokey protocol is designed so that after a few minutes
-the clients time out and restart the protocol from the beginning, with
-result the new generation is loaded and operation continues as before. A
-similar procedure can be used for the agreement parameter file, but in
-this case precautions must be take to be sure that all machines with
-this file have the same copy.
+<p>All key files are installed by default in <tt>/usr/local/etc</tt>, which is normally in a shared filesystem in NFS-mounted networks and avoids installing them in each machine separately. The default can be overridden by the <tt>keysdir</tt> configuration command. However, this is not a good place to install the private key file, since each machine needs its own file. A suitable place to install it is in <tt>/etc</tt>, which is normally not in a shared filesystem.
+
+<p>The recommended practice is to keep the timestamp extensions when installing a file and to install a link from the default name (without the timestamp extension) to the actual file. This allows new file generations to be activated simply by changing the link. However, <tt>ntpd</tt> parses the link name when present to extract the extension value and sends it along with the public key and host name when requested. This allows clients to verify that the file and generation time are always current. However, the actual location of each file can be overridden by the <tt>crypto</tt> configuration command.
+
+<p>All cryptographic keys and related parameters should be regenerated on a periodic and automatic basis, like once per month. The <tt>ntp-genkeys</tt> program uses the same timestamp extension for all files generated at one time, so each generation is distinct and can be readily recognized in monitoring data. While a public/private key pair must be generated by every server and client, the public keys and agreement parameters do not need to be explicitly copied to all machines in the same security compartment, since they can be obtained automatically using the Autokey protocol. However, it is necessary that all primary servers have the same agreement parameter file. The recommended way to do this is for one of the primary servers to generate that file and then copy it to the other primary servers in the same compartment using the Unix <tt>rdist</tt> command. Future versions of the Autokey protocol are to contain provisions for an agreement protocol to do this automatically.
+
+<p>Servers and clients can make a new generation in the following way. All machines have loaded the old generation at startup and are operating normally. At designated intervals, each machine generates a new public/private key pair and makes links from the default file names to the new file names. The <tt>ntpd</tt> is then restarted and loads the new generation, with result clients no longer can authenticate correctly. The Autokey protocol is designed so that after a few minutes the clients time out and restart the protocol from the beginning, with result the new generation is loaded and operation continues as before. A similar procedure can be used for the agreement parameter file, but in this case precautions must be take to be sure that all machines with this file have the same copy.
<h4>Authentication Commands</h4>
<dl>
<dt><tt>autokey [<i>logsec</i>]</tt>
-<dd>Specifies the interval between regenerations of the session key list
-used with the autokey protocol. Note that the size of the key list for
-each association depends on this interval and the current poll interval.
-The default value is 12 (4096 s or about 1.1 hours). For poll intervals
-above the specified interval, a session key list with a single entry
-will be regenerated for every message sent.</dd>
+<dd>Specifies the interval between regenerations of the session key list used with the Autokey protocol. Note that the size of the key list for each association depends on this interval and the current poll interval. The default value is 12 (4096 s or about 1.1 hours). For poll intervals above the specified interval, a session key list with a single entry will be regenerated for every message sent.</dd>
+
<dt><tt>controlkey <i>key</i></tt></dt>
-<dd>Specifies the key identifier to use with the <a
-href=ntpq.htm><tt>ntpq</tt></a> utility, which uses the standard
-protocol defined in RFC-1305. The <tt><i>key</i></tt> argument is the
-key identifier for a trusted key, where the value can be in the range 1
-to 65534, inclusive.</dd>
-
-<dt><tt>crypto [flags <i>flags</i>] [privatekey <i>file</i>] [publickey
-<i>file</i>] [dhparms <i>file</i>] [leap <i>file</i>] </tt></dt>
-<dd>This command requires the NTP daemon build process be configured
-with the RSA library. This command activates public-key cryptography and
-loads the required RSA private and public key files and the optional
-Diffie-Hellman agreement parameter file, if present. If one or more
-files are left unspecified, the default names are used as described
-below. Following are the subcommands:</dd>
+<dd>Specifies the key identifier to use with the <a href=ntpq.htm><tt>ntpq</tt></a> utility, which uses the standard protocol defined in RFC-1305. The <tt><i>key</i></tt> argument is the key identifier for a trusted key, where the value can be in the range 1 to 65534, inclusive.</dd>
-<dl>
+<dt><tt>crypto [flags <i>flags</i>] [privatekey <i>file</i>] [publickey <i>file</i>] [dhparms <i>file</i>] [leap <i>file</i>] </tt></dt> <dd>This command requires the NTP daemon build process be configured with the RSA library. This command activates public-key cryptography and loads the required RSA private and public key files and the optional Diffie-Hellman agreement parameter file, if present. If one or more files are left unspecified, the default names are used as described below. Following are the subcommands:</dd>
-<dt><tt>flags <i>flags</tt></i>
-<dd>Specifies optional flag bits. The only flag bit defined at this time
-is <tt>0x2</tt> which causes the leapsecond file to be fetched from any
-available server or peer.</dd>
+<dl>
<dt><tt>privatekey <i>file</tt></i>
-<dd>Specifies the location of the RSA private key file, which
-otherwise defaults to <tt>/usr/local/etc/ntpkey</tt>.</dd>
+<dd>Specifies the location of the RSA private key file, which otherwise defaults to <tt>/usr/local/etc/ntpkey</tt>.</dd>
<dt><tt>publickey <i>file</tt></i>
-<dd>Specifies the location of the RSA public key file, which otherwise
-defaults to <tt>/usr/local/etc/ntpkey_<i>host</i></tt>., where
-<i>host</i> is the name of the generating machine.</dd>
+<dd>Specifies the location of the RSA public key file, which otherwise defaults to <tt>/usr/local/etc/ntpkey_<i>host</i></tt>., where <i>host</i> is the name of the generating machine.</dd>
<dt><tt>dhparms <i>file</tt></i>
-<dd>Specifies the location of the Diffie-Hellman parameters file,
-which otherwise defaults to <tt>/usr/local/etc/ntpkey_dh</tt>.</dd>
-
+<dd>Specifies the location of the Diffie-Hellman parameters file, which otherwise defaults to <tt>/usr/local/etc/ntpkey_dh</tt>.</dd>
<dt><tt>leap <i>file</tt></i>
-<dd>Specifies the location of the leapsecond table file,
-which otherwise defaults to <tt>/usr/local/etc/ntpkey_leap</tt>.</dd>
+<dd>Specifies the location of the leapsecond table file, which otherwise defaults to <tt>/usr/local/etc/ntpkey_leap</tt>.</dd>
</dl>
<dt><tt>keys <i>keyfile</i></tt></dt>
-<dd>Specifies the location of the DES/MD5 private key file containing
-the keys and key identifiers used by <tt>ntpd</tt>, <tt>ntpq</tt> and
-<tt>ntpdc</tt> when operating in symmetric-key mode.</dd>
+<dd>Specifies the location of the DES/MD5 private key file containing the keys and key identifiers used by <tt>ntpd</tt>, <tt>ntpq</tt> and <tt>ntpdc</tt> when operating in symmetric-key mode.</dd>
<dt><tt>keysdir <i>path</i></tt></dt>
-<dd>This command requires the NTP daemon build process be configured
-with the RSA library. It specifies the default directory path for the
-private key file, agreement parameters file and one or more public key
-files. The default when this command does not appear in the
+<dd>This command requires the NTP daemon build process be configured with the RSA library. It specifies the default directory path for the private key file, agreement parameters file and one or more public key files. The default when this command does not appear in the
configuration file is <tt>/usr/local/etc/</tt>.</dd>
<dt><tt>requestkey <i>key</i></tt></dt>
-<dd>Specifies the key identifier to use with the <a
-href=ntpdc.htm><tt>ntpdc</tt></a> utility program, which uses a
-proprietary protocol specific to this implementation of <tt>ntpd</tt>.
-The <tt><i>key</i></tt> argument is a key identifier for the trusted
-key, where the value can be in the range 1 to 65534, inclusive.</dd>
+<dd>Specifies the key identifier to use with the <a href=ntpdc.htm><tt>ntpdc</tt></a> utility program, which uses a proprietary protocol specific to this implementation of <tt>ntpd</tt>. The <tt><i>key</i></tt> argument is a key identifier for the trusted key, where the value can be in the range 1 to 65534, inclusive.</dd>
<dt><tt>revoke [<i>logsec</i>]</tt>
-<dd>Specifies the interval between re-randomization of certain
-cryptographic values used by the autokey scheme, as a power of 2 in
-seconds. These values need to be updated frequently in order to deflect
-brute-force attacks on the algorithms of the scheme; however, updating
-some values is a relatively expensive operation. The default interval is
-16 (65,536 s or about 18 hours). For poll intervals above the specified
-interval, the values will be updated for every message sent.</dd>
+<dd>Specifies the interval between re-randomization of certain cryptographic values used by the Autokey scheme, as a power of 2 in seconds. These values need to be updated frequently in order to deflect brute-force attacks on the algorithms of the scheme; however, updating some values is a relatively expensive operation. The default interval is 16 (65,536 s or about 18 hours). For poll intervals above the specified interval, the values will be updated for every message sent.</dd>
<dt><tt>trustedkey <i>key</i> [...]</tt></dt>
-<dd>Specifies the key identifiers which are trusted for the purposes of
-authenticating peers with symmetric-key cryptography, as well as keys
-used by the <tt>ntpq</tt> and <tt>ntpdc</tt> programs. The
-authentication procedures require that both the local and remote servers
-share the same key and key identifier for this purpose, although
-different keys can be used with different servers. The
-<tt><i>key</i></tt> arguments are 32-bit unsigned integers with values
-from 1 to 65,534.</dd>
+<dd>Specifies the key identifiers which are trusted for the purposes of authenticating peers with symmetric-key cryptography, as well as keys used by the <tt>ntpq</tt> and <tt>ntpdc</tt> programs. The authentication procedures require that both the local and remote servers share the same key and key identifier for this purpose, although different keys can be used with different servers. The <tt><i>key</i></tt> arguments are 32-bit unsigned integers with values from 1 to 65,534.</dd>
</dl>
<h4>Bugs</h4>
-The <tt>ntpkey_<i>host</i></tt> files are really digital certificates.
-These should be obtained via secure directory services when they become
-universally available.
+The <tt>ntpkey_<i>host</i></tt> files are really digital certificates. These should be obtained via secure directory services when they become universally available.
-<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>
+<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>
<br clear=left>
<hr>
-<p>The Network Time Protocol (NTP) is used to synchronize the time of
-a computer client or server to another server or reference time source,
-such as a radio or satellite receiver or modem. It provides accuracies
-typically within a millisecond on LANs up to a few tens of milliseconds
-on WANs relative to Coordinated Universal Time (UTC), as provided by a
-Global Positioning Service (GPS) receiver, for example.
-
-<p>Typical NTP configurations utilize multiple redundant servers and
-diverse network paths, in order to achieve high accuracy and
-reliability. Some configurations include cryptographic authentication to
-prevent accidental or malicious protocol attacks. Information on the NTP
-architecture, protocol and algorithms can be found in the following
-articles and reports, which are available online. General issues of the
-concepts and facilities assumed by NTP are discussed in tne <a
-href=exec.htm>Executive Summary - Computer Network Time
-Synchronization</a> page, while issues related to the NTP timescale and
-pending century are discussed in the <A HREF=y2k.htm> Network Time
-Protocol Year 2000 Conformance Statement</A> page, both of which are
-included in this document.
-
-<p>Note that network timekeeping technology continues to advance and may
-obsolete some of the following documents. For a current list of all
-papers, reports, briefings and other documents relevant to the NTP
-community, see the <a href=http://www.eecis.udel.edu/~mills>David L.
-Mills</a> web page.
-
-<P>The NTP architecture, protocol and algorithm models are described in
-
-<UL>
-
-<li>Mills, D.L. Internet time synchronization: the Network Time
-Protocol. <I>IEEE Trans. Communications COM-39, 10</I> (October 1991),
-1482-1493. <A
-HREF=http://www.eecis.udel.edu/~mills/database/papers/trans.ps>
-PostScript</A> | <a
-HREF=http://www.eecis.udel.edu/~mills/database/papers/trans.pdf>
-PDF</a>. Also in: Yang, Z., and T.A. Marsland (Eds.). <I>Global States
-and Time in Distributed Systems</I>. IEEE Computer Society Press, Los
-Alamitos, CA, 1994, 91-102.
-</UL>
-
-The NTP specification and implementation has evolved over the last two
-decades to the current Version 4 of the protocol. This version includes
-significant enhancements in accuracy and reliability, as determined by
-experience in an estimated total of well over 100,000 clients and
-servers in the Internet, while retaining backward compatibility with
-previous versions.
-
-<P>This software distribution contains an implementation of the NTP
-Version 4 architecture, protocol and algorithms. While a formal
-specification of this version is not yet available, this version is
-fully compliant with the previous NTP Version 3 specification and
-implementation defined in
-<UL>
-
-<li>Mills, D.L. Network Time Protocol (Version 3) specification,
-implementation and analysis. Network Working Group Report RFC-1305,
-University of Delaware, March 1992, 113 pp. Abstract: <A
-HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.ps>
-PostScript)</A> | <a
-HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.pdf>
-PDF</A>, Body: <a
-HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps>
-PostScript)</A> | <a
-HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.pdf>
-PDF</A>, Appendices: <A
-HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps>
-PostScript</a> | <a
-HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf>
-PDF</A>.
-
-</UL>
-
-The NTP Version 4 implementation adds a number of extensions and
-refinements to the previous version, including an autonomous
-configuration and authentication capability, improved clock discipline
-algorithms capable of submicrosecond accuracy and many other
-refinements. Specific changes since the Version 3 specification was
-issued include:
-
-<OL>
-
-<p><LI>Support for precision-time kernel modifications, as described
-in</LI>
-
-<P>Mills, D.L. Unix kernel modifications for precision time
-synchronization. Electrical Engineering Department Report 94-10-1,
-University of Delaware, October 1994, 24 pp. Abstract: <A
-HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps>
-PostScript</A> | <a
-HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.pdf>
-PDF</a>, Body: <A
-HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps>
-PostScript</A> | <a
-HREF=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf>
-PDF</a>. Major revision and update of: Network Working Group Report
-RFC-1589, University of Delaware, March 1994. 31 pp. <A
-HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt>ASCII</A>
-
-<p><LI>Support for IP Multicasting, as described in</LI>
-
-<P>Mills, D.L, and A. Thyagarajan. Network time protocol version 4
-proposed changes. Electrical Engineering Department Report 94-10-2,
-University of Delaware, October 1994, 32 pp. Abstract: <A
-HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.ps>
-PostScript</A> | <A
-HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.pdf>
-PDF</A>, Body: <a
-HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.ps>
-PostScript</A> | <a
-HREF=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.pdf>
-PDF</a>
-
-<p><LI>A new hybrid phase/frequency-lock clock discipline, which
-replaces the RFC-1305 local clock algorithm, as described in</LI>
-
-
-<P>Mills, D.L. Clock discipline algorithms for the Network Time Protocol
-Version 4. Electrical Engineering Report 97-3-3, University of Delaware,
-March 1997, 35 pp. Abstract: <A
-HREF=http://www.eecis.udel.edu/~mills/database/reports/allan/securea.ps>
-PostScript</A> | <a
-HREF=
-http://www.eecis.udel.edu/~mills/database/reports/allan/securea.pdf>
-PDF</a>, Body: <A
-HREF=http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.ps>
-PostScript</A> | <a
-HREF=
-http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.pdf>
-PDF</a>
-
-<P>Mills, D.L. Improved algorithms for synchronizing computer network
-clocks. <I>IEEE/ACM Trans. Networks 3, 3</I> (June 1995), 245-254. <A
-HREF=http://www.eecis.udel.edu/~mills/database/papers/tune2.ps>
-PostScript</A> | <a
-HREF=http://www.eecis.udel.edu/~mills/database/papers/tune2.pdf>
-PDF</a>
-
-<P><LI>Engineered refinements to radio clock drivers and interface code,
-as describedin:</LI>
-
-<P>Mills, D.L. Precision synchronization of computer network clocks.
-<I>ACM Computer Communication Review 24, 2</I> (April 1994). 28-43. <A
-HREF=http://www.eecis.udel.edu/~mills/database/papers/fine.ps>
-PostScript</A> | <A
-HREF=http://www.eecis.udel.edu/~mills/database/papers/fine.pdf>
-PDF</a>
-
-<P><LI>Support for over two dozen reference clock drivers for all known
-national and international radio, satellite and modem standard time
-services known at this time. See the <A HREF=refclock.htm>Reference
-Clock Drivers </A>page.</LI>
-
-<P><LI>A new security model and authentication scheme based on public-
-key cryptography called <I>autokey</I>, as described in</LI>
-
-<P>Mills, D.L., T.S. Glassey, and M.E. McNeil. Coexistence and
-interoperability of NTP authentication schemes. Internet Draft
-draft-mills-ntp-auth-coexist-00.txt, University of Delaware and Coastek
-InfoSys, Inc., November 1997, 8 pp. <A
-HREF=http://www.eecis.udel.edu/~mills/memos/draft.txt>ASCII</A>
-
-<P>Mills, D.L. Authentication scheme for distributed, ubiquitous, real-
-time protocols. <I>Proc. Advanced Telecommunications/Information
-Distribution Research Program (ATIRP) Conference</I> (College Park MD,
-January 1997), 293-298. <A
-HREF=http://www.eecis.udel.edu/~mills/database/papers/atirp.ps>
-PostScript</A> | <a
-HREF=http://www.eecis.udel.edu/~mills/database/papers/atirp.pdf>
-PDF</a>
-
-<P>Mills, D.L. Proposed authentication enhancements for the Network Time
+<p>The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides accuracies typically within a millisecond on LANs up to a few tens of milliseconds on WANs relative to Coordinated Universal Time (UTC), as provided by a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths, in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks.
+
+<p>Information on the NTP architecture, protocol and algorithms can be found in the following articles and reports, which are available online. General issues of the concepts and facilities assumed by NTP are discussed in tHe <a href=exec.htm>Executive Summary - Computer Network Time Synchronization</a> page, while issues related to the NTP timescale and pending century are discussed in the <a href=y2k.htm> Network Time Protocol Year 2000 Conformance Statement</a> page, both of which are included in this software distribution.
+
+<p>Note that network timekeeping technology continues to advance and may obsolete some of the following documents. For a current list of all papers, reports, briefings and other documents relevant to the NTP community, see the <a href=http://www.eecis.udel.edu/~mills>David L. Mills</a> web page. A historical perspective is available in
+
+<ul>
+
+<p><li>Mills, D.L. A brief history of NTP time: confessions of an Internet timekeeper. Submitted for publication; please do not cite or redistribute. <a href=database/papers/history.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/history.pdf>PDF</a>
+
+</ul>
+
+<p>The NTP architecture, protocol and algorithm models are described in
+
+<ul>
+
+<p><li>Mills, D.L. Internet time synchronization: the Network Time Protocol. <I>IEEE Trans. Communications COM-39, 10</I> (October 1991), 1482-1493. <a href=http://www.eecis.udel.edu/~mills/database/papers/trans.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/trans.pdf> PDF</a>. Also in: Yang, Z., and T.A. Marsland (Eds.). <I>Global States and Time in Distributed Systems</I>. IEEE Computer Society Press, Los Alamitos, CA, 1994, 91-102.
+
+</ul>
+
+<p>The NTP specification and implementation has evolved over the last two decades to the current Version 4 of the protocol. This version includes significant enhancements in accuracy and reliability, as determined by experience in an estimated total of well over 100,000 clients and servers in the Internet, while retaining backward compatibility with previous versions.
+
+<p>This software distribution contains an implementation of the NTP Version 4 architecture, protocol and algorithms. While a formal specification of this version is not yet available, this version is fully compliant with the previous NTP Version 3 specification and implementation defined in
+<ul>
+
+<p><li>Mills, D.L. Network Time Protocol (Version 3) specification, implementation and analysis. Network Working Group Report RFC-1305, University of Delaware, March 1992, 113 pp. Abstract: <a
+href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.ps> PostScript)</a> | <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps> PostScript)</a> | <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.pdf> PDF</a>, Appendices: <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf> PDF</a>.
+
+</ul>
+
+<p>The NTP Version 4 implementation adds a number of extensions and refinements to the previous version, including an autonomous configuration and authentication capability, improved clock discipline algorithms capable of submicrosecond accuracy and many other refinements. Specific changes since the Version 3 specification was issued include:
+
+<ol>
+
+<p><li>Support for precision-time kernel modifications, as described in
+
+<p>Mills, D.L., and P.-H. Kamp. The nanokernel. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href=http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.pdf>PDF</a>, Slides: <a href=database/brief/nano/nano.htm>HTML</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/nano/nano.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/nano/nano.ppt>PowerPoint</a>
+
+<p>Mills, D.L. Unix kernel modifications for precision time synchronization. Electrical Engineering Department Report 94-10-1, University of Delaware, October 1994, 24 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kerna.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf> PDF</a>. Major revision and update of: Network Working Group Report RFC-1589, University of Delaware, March 1994. 31 pp. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt>ASCII</a>
+
+<p><li>Support for IP Multicasting, as described the <a href=assoc.htm>Association Management</a> page and in
+
+<p>Mills, D.L, and A. Thyagarajan. Network time protocol version 4 proposed changes. Electrical Engineering Department Report 94-10-2, University of Delaware, October 1994, 32 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsa.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.ps> PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/acts/actsb.pdf> PDF</a>
+
+<p><li>A new hybrid phase/frequency-lock clock discipline, which
+replaces the RFC-1305 local clock algorithm, as described in</li>
+
+<p>Mills, D.L. Improved algorithms for synchronizing computer network clocks. <I>IEEE/ACM Trans. Networks 3, 3</I> (June 1995), 245-254. <a href=http://www.eecis.udel.edu/~mills/database/papers/tune2.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/tune2.pdf>PDF</a>
+
+<p>Mills, D.L. Clock discipline algorithms for the Network Time Protocol Version 4. Electrical Engineering Report 97-3-3, University of Delaware, March 1997, 35 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/securea.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/securea.pdf> PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/allan/secureb.pdf>PDF</a>
+
+<p><li>Simple Network Monitoring Protocol (SNMP) monitoring tools, as described in</li>
+
+<p>Sethi, A.S., H. Gao, and D.L. Mills. Management of the Network Time Protocol (NTP) with SNMP. Computer and Information Sciences Report 98-09, University of Delaware, November 1998, 32 pp. <a href=http://www.eecis.udel.edu/~mills/database/reports/ntp-mib-tr.ps>PostScript</a> | <a href=database/reports/ntp-mib-tr.pdf>PDF</a>
+
+<p><li>Engineered refinements to radio clock drivers and interface code, as described in in the <a href=pps.htm>Pulse-per-second (PPS) Signal Interfacing</a> page and</li>
+
+<p>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. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc2783.txt>ASCII</a>
+
+<p>Mills, D.L. Precision synchronization of computer network clocks. <I>ACM Computer Communication Review 24, 2</I> (April 1994). 28-43. <a href=http://www.eecis.udel.edu/~mills/database/papers/fine.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/fine.pdf>PDF</a>
+
+<p><li>Support for over two dozen reference clock drivers for all known national and international radio, satellite and modem standard time services known at this time. See the <a href=refclock.htm>Reference Clock Drivers</a> page.</li>
+
+<p><li>A new security model and authentication scheme based on public-key cryptography called <I>Autokey</I>, as described in the <a href=authopt.htm>Authentication Options</a> page and in</li>
+
+<p>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>
+
+<p>Mills, D.L. Public key cryptography for the Network Time Protocol. Electrical Engineering Report 00-5-1, University of Delaware, May 2000. 23 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/pkey/pkeya.ps>PostScript</a> | <a href=database/reports/pkey/pkeya.pdf>PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/pkey/pkeyb.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/pkey/pkeyb.pdf>PDF</a>
+
+<p>Mills, D.L. Authentication scheme for distributed, ubiquitous, real-time protocols. <I>Proc. Advanced Telecommunications/Information Distribution Research Program (ATIRP) Conference</I> (College Park MD, January 1997), 293-298. <a href=http://www.eecis.udel.edu/~mills/database/papers/atirp.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/atirp.pdf>PDF</a>
+
+<p>Mills, D.L. Proposed authentication enhancements for the Network Time
Protocol version 4. Electrical Engineering Report 96-10-3, University of
-Delaware, October 1996, 36 pp. Abstract: <A
-HREF=
-http://www.eecis.udel.edu/~mills/database/reports/secure/securea.ps>
-PostScript</A> | <a
-HREF=
-http://www.eecis.udel.edu/~mills/database/reports/secure/securea.pdf>
-PDF</a>, Body: <A
-HREF=
-http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.ps>
-PostScript</A> | <a
-HREF=
-http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.pdf>
-PDF</a>
-
-<P><LI> Support for the MD5 cryptographic hash algorithm, in addition to
-the DES-CBC algorithm described in RFC-1305, as described in the <A
-HREF=ntpd.htm><TT>ntpd</TT> - Network Time Protocol (NTP) daemon
-</A>page.</LI>
-
-<P><LI>The prefer-peer scheme, as described in the <A
-HREF=prefer.htm>Mitigation Rules and the <TT>prefer</TT> Keyword
-</A>page.</LI>
-
-<P><LI>Specification for the Simple Network Time Protocol (SNTP), as
-described in</LI>
-
-<P>Mills, D.L. Simple network time protocol (SNTP) version 4 for IPv4,
-IPv6 and OSI. Network Working Group Report RFC-2030, University of
-Delaware, October 1996, 18 pp. <A
-HREF=http://www.eecis.udel.edu/~mills/database/rfc/rfc2030.txt>
-ASCII</A>. Obsoletes RFC-1769 and RFC-1361.
-
-<P><LI>Performance surveys for NTP Version 4 can be found in</LI>
-
-<p><li>Mills, D.L., A. Thyagarajan and B.C. Huffman. Internet
-timekeeping around the globe. <i>Proc. Precision Time and Time Interval
-(PTTI) Applications and Planning Meeting</i> (Long Beach CA, December
-1997), 365-371. Paper: <a
-href=http://www.eecis.udel.edu/~mills/database/papers/survey5.ps>
-PostScript</a> | <a
-href=http://www.eecis.udel.edu/~mills/database/papers/survey5.pdf>
-PDF</a>, Slides: <a
-href=
-http://www.eecis.udel.edu/~mills/database/brief/survey/survey/index.htm>
-HTML</a> | <a
-href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.ps>
-PostScript</a> | <a
-href=http://www.eecis.udel.edu/~mills/database/brief/survey.ppt>
-PowerPoint</a> | <a
-href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.pdf>
-PDF</a></li>
-
-<p><li>Mills, D.L. The network computer as precision timekeeper.
-<i>Proc. Precision Time and Time Interval (PTTI) Applications and
-Planning Meeting</i> (Reston VA, December 1996), 96-108. Paper: <a
-href=http://www.eecis.udel.edu/~mills/database/papers/ptti.ps>
-PostScript</a> | <a
-href=http://www.eecis.udel.edu/~mills/database/papers/ptti.pdf>
-PDF</a>, Slides: <a
-href=
-http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti/index.htm>
-HTML</a> | <a
-href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ps>
-PostScript</a> | <a
-href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ppt>
-PowerPoint</a> | <a
-href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.pdf>
-PDF</a></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>
+Delaware, October 1996, 36 pp. Abstract: <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/securea.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/securea.pdf>PDF</a>, Body: <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/reports/secure/secureb.pdf>PDF</a>
+
+<p><li> Support for the MD5 cryptographic hash algorithm, in addition to the DES-CBC algorithm described in RFC-1305, as described in the <a href=ntpd.htm><tt>ntpd</tt> - Network Time Protocol (NTP) daemon </a>page.</li>
+
+<p><li>The prefer-peer scheme, as described in the <a href=prefer.htm>Mitigation Rules and the <tt>prefer</tt> Keyword </a>page.</li>
+
+<p><li>Specification for the Simple Network Time Protocol (SNTP), as described in</li>
+
+<p>Mills, D.L. Simple network time protocol (SNTP) version 4 for IPv4, IPv6 and OSI. Network Working Group Report RFC-2030, University of Delaware, October 1996, 18 pp. <a href=http://www.eecis.udel.edu/~mills/database/rfc/rfc2030.txt>ASCII</a>. Obsoletes RFC-1769 and RFC-1361.
+
+<p><li>Support for International Atomic Time (TAI), as described in</li>
+
+<p>Levine, J., and D. Mills. Using the Network Time Protocol to transmit International Atomic Time (TAI). <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, November 2000). Paper: <a href=http://www.eecis.udel.edu/~mills/database/papers/tai.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/tai.pdf>PDF</a>
+
+<p><li>Performance surveys for NTP Version 4 can be found in</li>
+
+<p>Mills, D.L., A. Thyagarajan and B.C. Huffman. Internet timekeeping around the globe. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Long Beach CA, December 1997), 365-371. Paper: <a
+href=http://www.eecis.udel.edu/~mills/database/papers/survey5.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/survey5.pdf>PDF</a>, Slides: <a href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey/index.htm>HTML</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/survey.ppt>PowerPoint</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/survey/survey.pdf>PDF</a>
+
+<p>Mills, D.L. The network computer as precision timekeeper. <i>Proc. Precision Time and Time Interval (PTTI) Applications and Planning Meeting</i> (Reston VA, December 1996), 96-108. Paper: <a href=http://www.eecis.udel.edu/~mills/database/papers/ptti.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/papers/ptti.pdf>PDF</a>, Slides: <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti/index.htm>HTML</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ps>PostScript</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.ppt>PowerPoint</a> | <a href=http://www.eecis.udel.edu/~mills/database/brief/ptti/ptti.pdf>PDF</a>
+
+</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>
<h4>Reference Clock Support</h4>
-The NTP Version 4 daemon supports some three dozen different radio, satellite and modem reference clocks plus a special pseudo-clock used for backup or when no other clock source is available. Detailed descriptions of individual device drivers and options can be found in the <a HREF="refclock.htm">Reference Clock Drivers </a>page. Additional information can be found in the pages linked there, including the <a HREF="rdebug.htm">Debugging Hints for Reference Clock Drivers</a> and <a HREF="howto.htm
l">How To Write a Reference Clock Driver</a> pages. In addition, support for a PPS signal is available as described in <a HREF="pps.htm">Pulse-per-second (PPS) Signal Interfacing</a> page. Many drivers support special line discipline/streams modules which can significantly improve the accuracy using the driver. These are described in the <a HREF="ldisc.htm">Line Disciplines and Streams Drivers</a>
+The NTP Version 4 daemon supports some three dozen different radio, satellite and modem reference clocks plus a special pseudo-clock used for backup or when no other clock source is available. Detailed descriptions of individual device drivers and options can be found in the <a HREF="refclock.htm">Reference Clock Drivers </a>page. Additional information can be found in the pages linked there, including the <a HREF="rdebug.htm">Debugging Hints for Reference Clock Drivers</a> and <a HREF="howto.htm">How To Write a Reference Clock Driver</a> pages. In addition, support for a PPS signal is available as described in <a HREF="pps.htm">Pulse-per-second (PPS) Signal Interfacing</a> page. Many drivers support special line discipline/streams modules which can significantly improve the accuracy using the driver. These are described in the <a HREF="ldisc.htm">Line Disciplines and Streams Drivers</a>
page.
<p>A reference clock will generally (though not always) be a radio timecode receiver which is synchronized to a source of standard time such as the services offered by the NRC in Canada and NIST and USNO in the US. The interface between the computer and the timecode receiver is device dependent, but is usually a serial port. A device driver specific to each reference clock must be selected and compiled in the distribution; however, most common radio, satellite and modem clocks are included by default. Note that an attempt to configure a reference clock when the driver has not been compiled or the hardware port has not been appropriately configured results in a scalding remark to the system log file, but is otherwise non hazardous.
<h4>Configuration Support</h4>
-<p>Following is a description of the configuration commands in NTPv4.
-These commands have the same basic functions as in NTPv3 and in some
-cases new functions and new arguments. There are two classes of
-commands, configuration commands that configure a persistent association
-with a remote server or peer or reference clock, and auxilliary commands
-that specify environmental variables that control various related
-operations.
+<p>Following is a description of the configuration commands in NTPv4. These commands have the same basic functions as in NTPv3 and in some cases new functions and new arguments. There are two classes of commands, configuration commands that configure a persistent association with a remote server or peer or reference clock, and auxilliary commands that specify environmental variables that control various related operations.
<h4>Configuration Commands</h4>
-<p>The various modes are determined by the command keyword and the type
-of the required IP address. Addresses are classed by type as (s) a
-remote server or peer (IP class A, B and C), (b) the broadcast address
-of a local interface, (m) a multicast address (IP class D), or (r) a
-reference clock address (127.127.x.x). Note that some options are not
-supported by all these commands while autokey and burst modes are
-supported by these commands, their effect in some weird mode
-combinations can be meaningless or even destructive.
-
+<p>The various modes are determined by the command keyword and the type of the required IP address. Addresses are classed by type as (s) a remote server or peer (IP class A, B and C), (b) the broadcast address of a local interface, (m) a multicast address (IP class D), or (r) a reference clock address (127.127.x.x). Note that only those options applicable to each command are listed below. Use of options not listed may not be caught as an error, but may result in some weird and even destructive behavior.
<dl>
-<dt><tt>peer <i>address</i> [key <i>key</i> | autokey] [version
-<i>version</i>] [prefer] [minpoll <i>minpoll</i>] [maxpoll
-<i>maxpoll</i>]</tt></dt>
+<dt><tt>peer <i>address</i> [key <i>key</i> | autokey] [version <i>version</i>] [prefer] [minpoll <i>minpoll</i>] [maxpoll <i>maxpoll</i>]</tt></dt>
-<p><dt><tt>server <i>address</i> [key <i>key</i> | autokey] [burst]
-[iburst] [version <i>version</i>] [prefer] [minpoll <i>minpoll</i>]
-[maxpoll <i>maxpoll</i>]</tt></dt>
+<p><dt><tt>server <i>address</i> [key <i>key</i> | autokey] [burst] [iburst] [version <i>version</i>] [prefer] [minpoll <i>minpoll</i>] [maxpoll <i>maxpoll</i>]</tt></dt>
-<p><dt><tt>broadcast <i>address</i> [key <i>key</i> | autokey] [version
-<i>version</i>] [minpoll <i>minpoll</i>] [ttl <i>ttl</i>]</tt></dt>
+<p><dt><tt>broadcast <i>address</i> [key <i>key</i> | autokey] [version <i>version</i>] [minpoll <i>minpoll</i>] [ttl <i>ttl</i>]</tt></dt>
-<p><dt><tt>manycastclient <i>address</i> [key <i>key</i> | autokey]
-[version <i>version</i>] [minpoll <i>minpoll</i> [ttl
-<i>ttl</i>]</tt></dt>
+<p><dt><tt>manycastclient <i>address</i> [key <i>key</i> | autokey] [version <i>version</i>] [minpoll <i>minpoll</i> [maxpoll <i>maxpoll</i>] [ttl <i>ttl</i>]</tt></dt>
-<p><dd>These four commands specify the time server name or address to
-be used and the mode in which to operate. The <i>address</i> can be
-either a DNS name or a IP address in dotted-quad notation. Additional
-information on association behavior can be found in the <a
-href="assoc.htm">Association Management</a> page.</dd>
+<p><dd>These four commands specify the time server name or address to be used and the mode in which to operate. The <i>address</i> can be either a DNS name or a IP address in dotted-quad notation. Additional information on association behavior can be found in the <a href="assoc.htm">Association Management</a> page.</dd>
<dd><dl>
<dt><tt>server</tt></dt>
-<dd>For type s and r addresses, this operates as the NTPv3 server
-command, which mobilizes a persistent client mode association. The
-<tt>server</tt> command specifies that the local server is to operate in
-client mode with the specified remote server. In this mode, the local
-server can be synchronized to the remote server, but the remote server
-can never be synchronized to the local server.</dd>
+<dd>For type s and r addresses, this command mobilizes a persistent client mode association with the specified remote server or local radio clock. In this mode the local clock can synchronized to the remote server, but the remote server can never be synchronized to the local clock. This command should NOT be used for type <tt>b</tt> or <tt>m</tt> addresses.</</dd>
<dt><tt>peer</tt></dt>
-<dd>For type s addresses (only), this operates as the current <tt>peer
-</tt>command, which mobilizes a persistent symmetric-active mode
-association, except that additional modes are available. This command
-should NOT be used for type <tt>b</tt>, <tt>m</tt> or <tt>r</tt>
-addresses.</dd>
-
-<p><dd>The <tt>peer</tt> command specifies that the local server is to
-operate in symmetric active mode with the remote server. In this mode,
-the local server can be synchronized to the remote server and, in
-addition, the remote server can be synchronized by the local server.
-This is useful in a network of servers where, depending on various
-failure scenarios, either the local or remote server may be the better
-source of time.</dd>
+<dd>For type s addresses (only), this command mobilizes a persistent symmetric-active mode association with the specified remote peer. In this mode the local clock can be synchronized to the remote peer or the remote peer can be synchronized to the local clock. This is useful in a network of servers where, depending on various failure scenarios, either the local or remote peer may be the better source of time. This command should NOT be used for type <tt>b</tt>, <tt>m</tt> or <tt>r</tt> addresses.</dd>
<dt><tt>broadcast</tt></dt>
-<dd>For type <tt>b</tt> and <tt>m</tt> addresses (only), this operates
-as the current NTPv3 <tt>broadcast </tt>command, which mobilizes a
-persistent broadcast mode association, except that additional modes are
-available. Multiple commands can be used to specify multiple local
-broadcast interfaces (subnets) and/or multiple multicast groups. Note
-that local broadcast messages go only to the interface associated with
-the subnet specified, but multicast messages go to all interfaces. In
-the current implementation, the source address used for these messages
-is the Unix host default address.</dd>
-
-<p><dd>In broadcast mode, the local server sends periodic broadcast
-messages to a client population at the <i><tt>address</tt></i>
-specified, which is usually the broadcast address on (one of) the local
-network(s) or a multicast address assigned to NTP. The IANA has assigned
-the multicast group address 224.0.1.1 exclusively to NTP, but other
-nonconflicting addresses can be used to contain the messages within
-administrative boundaries. Ordinarily, this specification applies only
-to the local server operating as a sender; for operation as a broadcast
-client, see the <tt>broadcastclient</tt> or <tt>multicastclient</tt>
-commands below.</dd>
+<dd>For type <tt>b</tt> and <tt>m</tt> addresses (only), this command mobilizes a persistent broadcast mode association. Multiple commands can be used to specify multiple local broadcast interfaces (subnets) and/or multiple multicast groups. Note that local broadcast messages go only to the interface associated with the subnet specified, but multicast messages go to all interfaces.</dd>
+
+<p><dd>In broadcast mode the local server sends periodic broadcast messages to a client population at the <i><tt>address</tt></i> specified, which is usually the broadcast address on (one of) the local network(s) or a multicast address assigned to NTP. The IANA has assigned the multicast group address 224.0.1.1 exclusively to NTP, but other nonconflicting addresses can be used to contain the messages within administrative boundaries. Ordinarily, this specification applies only to the local server operating as a sender; for operation as a broadcast client, see the <tt>broadcastclient</tt> or <tt>multicastclient</tt> commands below.</dd>
<dt><tt>manycastclient</tt>
-<dd>For type <tt>m</tt> addresses (only), this mobilizes a manycast
-client-mode association for the multicast address specified. In this
-case a specific address must be supplied which matches the address used
-on the <tt>manycastserver</tt> command for the designated manycast
-servers. The NTP multicast address 224.0.1.1 assigned by the IANA should
-NOT be used, unless specific means are taken to avoid spraying large
-areas of the Internet with these messages and causing a possibly massive
-implosion of replies at the sender. </dd>
-
-<p><dd>The <tt>manycast</tt> command specifies that the local server is
-to operate in client mode with the remote servers that are discovered as
-the result of broadcast/multicast messages. The client broadcasts a
-request message to the group address associated with the specified
-<i><tt>address</tt></i> and specifically enabled servers respond to
-these messages. The client selects the servers providing the best time
-and continues as with the <tt>server</tt> command. The remaining servers
-are discarded as if never heard.</dd>
+<dd>For type <tt>m</tt> addresses (only), this command mobilizes a manycast client mode association for the multicast address specified. In this case a specific address must be supplied which matches the address used on the <tt>manycastserver</tt> command for the designated manycast servers. The NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used, unless specific means are taken to avoid spraying large areas of the Internet with these messages and causing a possibly massive implosion of replies at the sender. </dd>
+
+<p><dd>The <tt>manycast</tt> command specifies that the local server is to operate in client mode with the remote servers that are discovered as the result of broadcast/multicast messages. The client broadcasts a request message to the group address associated with the specified <i><tt>address</tt></i> and specifically enabled servers respond to these messages. The client selects the servers providing the best time and continues as with the <tt>server</tt> command. The remaining servers are discarded as if never heard.</dd>
</dl>
<dl><dd>
<dt><tt>autokey</tt></dt>
-<dd>All packets sent to and received from the server or peer are to
-include authentication fields encrypted using the autokey scheme
-described in the <a href=authopt.htm>Authentication Options</a>
-page.</dd>
+<dd>All packets sent to and received from the server or peer are to include authentication fields encrypted using the autokey scheme described in the <a href=authopt.htm>Authentication Options</a> page.</dd>
<dt><tt>burst</tt></dt>
-<dd>At each poll interval, send a burst of eight packets spaced at 1-s
-intervals instead of the usual one.</dd>
+<dd>At each poll interval, send a burst of eight packets instead of the usual one packet. The spacing between the first and the second packets is about 20s to allow a modem call to complete, while the spacing between the remaining packets is about 2s. This is designed to improve timekeeping quality with the <tt>server</tt> command and <tt>s</tt> addresses.</dd>
+
<dt><tt>iburst</tt></dt>
-<dd>At the first poll interval, send a burst of eight packets spaced at
-1-s intervals instead of the usual one.</dd>
+<dd>At the first poll interval, send a burst of eight packets instead of the usual one. The spacing between the first and the second packets is about 20s to allow a modem call to complete, while the spacing between the remaining packets is about 2s. This is designed to speed the initial synchronization acquisition with the <tt>server</tt> command and <tt>s</tt> addresses.</dd>
<dt><tt>key </tt><i><tt>key</tt></i></dt>
-<dd>All packets sent to and received from the server or peer are to
-include authentication fields encrypted using the specified <i>key</i>
-identifier with values from 1 to 65534, inclusive. The default is to
-include no encryption field.</dd>
+<dd>All packets sent to and received from the server or peer are to include authentication fields encrypted using the specified <i>key</i> identifier with values from 1 to 65534, inclusive. The default is to include no encryption field.</dd>
<dt><tt>minpoll <i>minpoll</i></tt>
<br><tt>maxpoll <i>maxpoll</i></tt>
-<dd>These options specify the minimum and maximum polling intervals for
-NTP messages, in seconds to the power of two. The default range is 6 (64
-s) to 10 (1,024 s). The allowable range is 4 (16 s) to 17 (36.4 h)
-inclusive.</dd>
+<dd>These options specify the minimum and maximum polling intervals for NTP messages, in seconds to the power of two. The default range is 6 (64 s) to 10 (1,024 s). The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.</dd>
<dt><tt>prefer</tt></dt>
-<dd>Marks the server as preferred. All other things being equal, this
-host will be chosen for synchronization among a set of correctly
-operating hosts. See the <a href="prefer.htm">Mitigation Rules and the
-<tt>prefer</tt> Keyword </a>page for further information.</dd>
+<dd>Marks the server as preferred. All other things being equal, this host will be chosen for synchronization among a set of correctly operating hosts. See the <a href="prefer.htm">Mitigation Rules and the <tt>prefer</tt> Keyword </a>page for further information.</dd>
<dt><tt>ttl <i>ttl</i></tt></dt>
-<dd>This option is used only with broadcast mode. It specifies the
-time-to-live <i><tt>ttl</tt></i> to use on multicast packets. Selection
-of the proper value, which defaults to 127, is something of a black art
-and must be coordinated with the network administrator.</dd>
+<dd>This option is used only with broadcast server and manycast client modes. It specifies the time-to-live <i><tt>ttl</tt></i> to use on broadcast server and multicast server and the maximum <i><tt>ttl</tt></i> for the expanding ring search with manycast client packets. Selection of the proper value, which defaults to 127, is something of a black art and should be coordinated with the network administrator.</dd>
<dt><tt>version <i>version</i></tt></dt>
-<dd>Specifies the version number to be used for outgoing NTP packets.
-Versions 1-4 are the choices, with version 4 the default.</dd>
+<dd>Specifies the version number to be used for outgoing NTP packets. Versions 1-4 are the choices, with version 4 the default.</dd>
</dl></dd></dl></dd>
<dl>
<dt><tt>broadcastclient</tt>
-<dd>This command directs the local server to listen for and respond to
-broadcast messages received on any local interface. Upon hearing a
-broadcast message for the first time, the local server measures the
-nominal network delay using a brief client/server exchange with the
-remote server, then enters the broadcastclient mode, in which it listens
-for and synchronizes to succeeding broadcast messages. Note that, in
-order to avoid accidental or malicious disruption in this mode, both the
-local and remote servers should operate using authentication and the
-same trusted key and key identifier.</dd>
+<dd>This command enables reception of broadcast server messages to any local interface (type b) address. Upon receiving a message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding broadcast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the <a href=authopt.htm>Authentication Options</a> page.</dd>
<dt><tt>manycastserver <i>address</i> [...]</tt>
-<dd>This command directs the local server to listen for and respond to
-broadcast messages received on any local interface, and in addition
-enables the server to respond to client mode messages to the multicast
-group address(es) (type m) specified. At least one address is required,
-but The NTP multicast address 224.0.1.1 assigned by the IANA should NOT
-be used, unless specific means are taken to limit the span of the reply
-and avoid a possibly massive implosion at the original sender.</dd>
+<dd>This command enables reception of manycast client messages to the multicast group address(es) (type m) specified. At least one address is required, but The NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used, unless specific means are taken to limit the span of the reply and avoid a possibly massive implosion at the original sender. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the <a href=authopt.htm>Authentication Options</a> page.</dd>
<dt><tt>multicastclient [<i>address</i>] [...]</tt>
-<dd>This command directs the local server to listen for multicast
-messages at the group address(es) of the global network. The default
-address is that assigned by the Numbers Czar to NTP (224.0.1.1). This
-command operates in the same way as the <tt>broadcastclient</tt>
-command, but uses IP multicasting. Support for this command requires
-multicast kernel support.</dd>
+<dd>This command enables reception of multicast server messages to the multicast group address(es) (type m) specified. Upon receiving a message for the first time, the multicast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding multicast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the <a href=authopt.htm>Authentication Options</a> page.</dd>
</dl>
<h4>Bugs</h4>
-<p>The syntax checking is not picky; some combinations of ridiculous and
-even hilarious options and modes may not be detected.
+<p>The syntax checking is not picky; some combinations of ridiculous and even hilarious options and modes may not be detected.
-<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>
+<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>
Network Performance Evaluation
</h3><hr>
-<p>The technical memorandum: <cite>Time and Time Interval Measurement
-with Application to Computer and Network Performance Evaluation</cite><a
-href="http://www.eecis.udel.edu/~mills/database/memos/memo96a.ps">
-(PostScript) </a> describes a number of techniques for conducting
-experiments typical of computer network and transmission systems
-engineering.
+<p>The technical memorandum: <cite>Time and Time Interval Measurement with Application to Computer and Network Performance Evaluation</cite><a href="http://www.eecis.udel.edu/~mills/database/memos/memo96a.ps">(PostScript) </a> describes a number of techniques for conducting experiments typical of computer network and transmission systems engineering.
-<p>In most experiments in which time is involved, it is necessary to
-develop estimates of time, frequency and measurement errors from a
-series of time measurements between the clocks of a number of computers
-and ancillary devices interconnected by some kind of computer network.
-However, time is not a physical quantity, such as mass, nor can it be
-measured relative to an absolute frame of reference, such as velocity.
-The only way to measure time in our universe is to compare the reading
-of one clock, which runs according to its own timescale, with another
-clock, which runs according to a given timescale, at some given instant
-or epoch. The errors arise from the precision of time comparisons and
-the accuracy of frequency estimates between the timescales involved.
+<p>In most experiments in which time is involved, it is necessary to develop estimates of time, frequency and measurement errors from a series of time measurements between the clocks of a number of computers and ancillary devices interconnected by some kind of computer network. However, time is not a physical quantity, such as mass, nor can it be measured relative to an absolute frame of reference, such as velocity. The only way to measure time in our universe is to compare the reading of one clock, which runs according to its own timescale, with another clock, which runs according to a given timescale, at some given instant or epoch. The errors arise from the precision of time comparisons and the accuracy of frequency estimates between the timescales involved.
-<p>The usual data collected during a performance run of some experiment
-might include time offsets, time delays, frequency offsets and various
-error statistics. While time offsets between two clocks can be measured
-directly, frequency offsets can be estimated only from two or more time
-offsets made over some time interval in the experiment. In practice, a
-sequence of time comparisons can be performed over the lifetime of the
-experiment and the instantaneous frequency estimated either in real time
-with a recurrence relation, or retrospectively with a polynomial fit to
-the data.
+<p>The usual data collected during a performance run of some experiment might include time offsets, time delays, frequency offsets and various error statistics. While time offsets between two clocks can be measured directly, frequency offsets can be estimated only from two or more time offsets made over some time interval in the experiment. In practice, a sequence of time comparisons can be performed over the lifetime of the experiment and the instantaneous frequency estimated either in real time with a recurrence relation, or retrospectively with a polynomial fit to the data.
-<p>Estimating time and frequency errors in real time has been studied by
-a distinct subspecies of physicists who have made a career of the
-technology involved. Various means including autoregressive models,
-Kalman filters and simple weighted-average algorithms are used
-extensively by national standards laboratories to model cesium-clock
-ensembles. These techniques have been adapted to computer network and
-transmission engineering problems as well. This memorandum explores
-issues in performing experiments of this type and summarizes various
-techniques found useful in practice.
+<p>Estimating time and frequency errors in real time has been studied by a distinct subspecies of physicists who have made a career of the technology involved. Various means including autoregressive models, Kalman filters and simple weighted-average algorithms are used extensively by national standards laboratories to model cesium-clock ensembles. These techniques have been adapted to computer network and transmission engineering problems as well. This memorandum explores issues in performing experiments of this type and summarizes various techniques found useful in practice.
-<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>
+<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>
Patching Procedures
</h3>
-<IMG align=left SRC=pic/rabbit.gif>From <i>pogo</i>, Walt Kelly
+<img align=left src=pic/rabbit.gif>From <i>pogo</i>, Walt Kelly
<br clear=left><hr>
-<p>A distribution so widely used as this one eventually develops
-numerous barnacles as the result of <a href=porting.htm>porting</a>
-to new systems, idiosyncratic new features and just plain bugs. In order
-to help keep order and make maintenance bearable, we ask that proposed
-changes to the distribution be submitted in the following form.
+<p>A distribution so widely used as this one eventually develops numerous barnacles as the result of <a href=porting.htm>porting</a> to new systems, idiosyncratic new features and just plain bugs. In order to help keep order and make maintenance bearable, we ask that proposed changes to the distribution be submitted in the following form.
<ol>
-<p><li>Please submit patches to <a href=mailto:mills@udel.edu>David L.
-Mills <mills@udel.edu></a> in the form of either unified-diffs
-(<tt>diff -u</tt>) or context-diffs (<tt>diff -c</tt>).</li>
+<p><li>Please submit patches to <a href=mailto:bugs@mail.ntp.org>Bugs <bugs@mail.ntp.org></a> in the form of either unified-diffs (<tt>diff -u</tt>) or context-diffs (<tt>diff -c</tt>).</li>
-<p><li>Please include the <strong>output</strong> from
-<tt>config.guess</tt> in the description of your patch. If
-<tt>config.guess</tt> does not produce any output for your machine,
-please fix that, too!</li>
+<p><li>Please include the <strong>output</strong> from <tt>config.guess</tt> in the description of your patch. If <tt>config.guess</tt> does not produce any output for your machine, please fix that, too!</li>
-<p><li>Please base the patch on the root directory of the distribution.
-The preferred procedure here is to copy your patch to the root directory
-and mumble</li>
+<p><li>Please base the patch on the root directory of the distribution. The preferred procedure here is to copy your patch to the root directory and mumble</li>
<p><tt>patch -p <your_patch></tt></li>
-<p><li>Please avoid patching the RCS subdirectories; better yet, clean
-them out before submitting patches.</li>
+<p><li>Please avoid patching the RCS subdirectories; better yet, clean them out before submitting patches.</li>
-<p><li>If you have whole new files, as well as patches, wrap the files
-and patches in a shell script. If you need to compress it, use either
-GNU zip or the stock Unix compress utility.</li>
+<p><li>If you have whole new files, as well as patches, wrap the files and patches in a shell script. If you need to compress it, use either GNU zip or the stock Unix <tt>compress</tt> utility.</li>
-<p><li>Don't forget the documentation that may be affected by the patch.
-Send us patches for the <tt>./html</tt> files as well. See the <a
-href=htmlprimer.htm>A Beginner's Guide to HTML</a> page for a
-tutorial.</li>
+<p><li>Don't forget the documentation that may be affected by the patch. Send us patches for the <tt>./htm</tt> files as well. See the <a href=htmlprimer.htm>A Beginner's Guide to HTML</a> page for a tutorial.</li>
-<p><li>We would be glad to include your name, electric address and
-descriptive phrase in the <a href=copyright.htm>Copyright</a> page,
-if you wish.</li>
+<p><li>We would be glad to include your name, electric address and descriptive phrase in the <a href=copyright.htm>Copyright</a> page, if you wish.</li>
</ol>
-<p>Prior to ntp3-5.83 (releases up to and including ntp3.5f) a
-complete patch history back to the dark ages was kept in the
-<tt>./patches</tt> directory, which might have been helpful to see
-if the same problem occured in another port, etc. Patches were saved in
-that directory with file name in the form <tt>patch.<i>nnn</i></tt>,
-where <i>nnn</i> was approaching 200. All patches in that directory have
-been made; so, if yours was there, it was in the distribution.
-
-<p>Since we have been getting multple patches for some bugs, plus many
-changes are implemented locally, no two maintainers here use the same
-tools, and since we're not using any bug-tracking software or even
-source code control, there is currently no tracking of specific changes.
-
-<p>The best way to see what's changed between two distributions is to
-run a <tt>diff</tt> against them.
+<p>Prior to ntp3-5.83 (releases up to and including ntp3.5f) a complete patch history back to the dark ages was kept in the <tt>./patches</tt> directory, which might have been helpful to see if the same problem occured in another port, etc. Patches were saved in that directory with file name in the form <tt>patch.<i>nnn</i></tt>, where <i>nnn</i> was approaching 200. All patches in that directory have been made; so, if yours was there, it was in the distribution.
+
+<p>Since we have been getting multple patches for some bugs, plus many changes are implemented locally, no two maintainers here use the same tools, and since we're not using any bug-tracking software or even source code control, there is currently no tracking of specific changes.
+<p>The best way to see what's changed between two distributions is to run a <tt>diff</tt> against them.
+
<p>Thanks for your contribution and happy chime.
-<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>
+<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>
-<HTML><HEAD><TITLE>
+<html><head><title>
NTP Version 4 Release Notes
-</TITLE></HEAD><BODY><H3>
+</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 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.
-
-<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>There are two <A HREF=assoc.htm>burst-mode</A> 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>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
-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 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
-<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 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.</LI>
-
-<P><LI>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 <TT>fudge 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 precede 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-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:
-
-<OL>
-
-<p><li>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>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 latest release of NTP4 includes support for tne <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. 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>.</LI>
-
-<p><li>A new pulse-per-second (PPS) generic interface described in <a
-href=http://www.eecis.udel.edu/~mills/reports.htm>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</a> is supported. Older
-interfaces and line disciplines continue to be supported, but may be
-withdrawen in future versions.
-
-<P><LI>On Alpha 4.0 with reference clocks configured, debugging with the
-<TT>-d</TT> options doesn't work.</LI>
-
-<P><LI>The latest release of NTPv4 includes support for <i>autokey</i>
-public-key cryptography, which is the preferred scheme for
-authenticating servers to clients. It uses NTP header extensions fields
-documented in <a
-href=http://www.eecis.udel.edu/~mills/reports.htm>Mills, D.L. Public key
-cryptography for the Network Time Protocol. Electrical Engineering
-Report 00-5-1, University of Delaware, May 2000. 23 pp</a> 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 <a
-href=authopt.htm>Authentication Options</a> page and links from
-thnere.</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>
+</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>
+
+<p>This document was last updated 14 December 2000
+
+<h4>NTP Version 4 Release Notes</h4>
+
+<p>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.
+
+<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>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.
+
+<ol>
+
+<p><li>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.</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>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>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.</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 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. See the <a href=assoc.htm>Association Management</a> page for further information.</li>
+
+<p><li>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 rocedure. See the <a href=assoc.htm>Association Management</a> page for further information.</li>
+
+<p><li>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 <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 self-synchronize and 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 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.</li>
+
+<p><li>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.</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) 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.</li>
+
+<p><li>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 <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.</li>
+
+</ol>
+
+<h4>Caveats</h4>
+
+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:
+
+<ol>
+
+<p><li>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>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>.</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>
extern void crypto_config P((int, char *));
extern void crypto_setup P((void));
extern int crypto_public P((struct peer *, u_char *, u_int));
+#endif /* PUBKEY */
/*
* Cryptographic values
*/
+extern u_int crypto_flags; /* status word */
+#ifdef PUBKEY
extern R_DH_PARAMS dh_params;
extern struct value host; /* host name/public key */
extern struct value dhparam; /* agreement parameters */
projects / thirdparty / ntp.git / commitdiff
