authentication scheme is applicable in this mode, as well as the
new NTPv4 Autokey proventication scheme.</p>
-<h4>Broadcast Mode</h4>
+<h4>Broadcast/Multicast Modes</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>
<p>Broadcast mode is intended for configurations involving one or a
few servers and a possibly very large client population. A
server continues as before and the client sends no further
messages.</p>
-<h4>IP Broadcast Mode</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>
-
-<h4>IP Multicast Support</h4>
-
-<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, or GLOP
-group addresses, as described in RFC-2770.</p>
-
<h4>Multicasting</h4>
<p>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>
+subnet in two ways: multicasting and manycasting. A general
+discussion of IP multicast technology is beyond the scope of this
+page. 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, or GLOP group addresses, as described in
+RFC-2770.</p>
+
+<p>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>
<p>IP multicasting is a different paradigm. A multicast message has
the same format as a broadcast message and is configured with the
<h4>Burst Modes</h4>
-<p>There are two burst modes where a single poll triggers a burst
-of eight packets instead of the usual one. The <tt>burst</tt> mode
-sends a burst when the server is reachable, while the <tt>
+<p>There are two burst modes where a single poll event triggers a
+burst of eight packets instead of the usual one. The <tt>burst</tt>
+mode sends a burst when the server is reachable, while the <tt>
iburst</tt> mode sends a burst when the server is unreachable. Each
mode is independently of the other and both can be used if
necessary. When the server is reachable, the packet spacing is a
using the <tt>key</tt> or <tt>autokey</tt> subcommand on the <tt>
peer</tt>, <tt>server</tt>, <tt>broadcast</tt> and <tt>
manycastclient</tt> configuration commands as described in the <a
-href="config.htm">Configuration Options</a> page. The
+href="confopt.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. In addition, if public key cryptography
is enabled, the commands specify the message digest and signature
encryption scheme.</p>
+<p>Authentication is always enabled, although ineffective if no
+keys are configured as described below. If a NTP packet arrives
+including a message authentication code (MAC), only if it passes
+all cryptographic checks is it accepted for further processing. The
+checks require correct key ID, key value and message contents. If
+the packet has been modified in any way or replayed by an intruder,
+it will fail one or more of these checks and be discarded.
+Furthermore, the Autokey scheme requires a preliminary protocol
+exchange to obtain the server public key, verify its credentials
+and compute a private session key.</p>
+
<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>
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 system timekeeping.</p>
+authenticated.</p>
+
+<p>It should be understood that operating with the <tt>auth</tt>
+disabled invites a significant vulnerability where a rogue hacker
+can seriously disrupt system timekeeping. It is important to note
+that this flag has no purpose other than to allow or disallow a new
+association in response to new broadcast client and symmetric
+passive associations and remote configuration commands and, in
+particular, the flag has no effect on the authentication process
+itself.</p>
<p>In networks with firewalls and large numbers of broadcast
clients it may be acceptable to disable authentication, since that
<p>An attractive alternative where multicast support is available
is manycast mode, in which clients periodically troll for servers
as described in the <a href="assoc.htm">Association Management</a>
-page. . Cryptographic authentication in this mode the Autokey
+page. Cryptographic authentication in this mode the Autokey
protocol described below. The principle advantage of manycast mode
is that potential servers need not be configured in advance, since
the client finds them during regular operation, and the
the X.509 certificate configured during installation along with the
matching sign key. There are several schemes available in the
OpenSSL software library, each identified by a specific string such
-as <tt>RSA_MD5</tt>, which stands for the MD5 message digest with
-RSA encryption scheme. The current NTP distribution supports all
-the schemes in the OpenSSL library, including those based on RSA
-and DSA digital signatures. The schemes currently available are
-described in the <a href="genkeys.htm"><tt>ntp-genkeys</tt></a>
-page.</p>
+as <tt>md5WithRSAEncryption</tt>, which stands for the MD5 message
+digest with RSA encryption scheme. The current NTP distribution
+supports all the schemes in the OpenSSL library, including those
+based on RSA and DSA digital signatures. The schemes currently
+available are described in the <a href="genkeys.htm"><tt>
+ntp-genkeys</tt></a> page.</p>
<p>The digest/signature scheme and certificate are provided to
dependent clients in the Autokey protocol. Different client or peer
associations can use different schemes; each of two symmetric peers
can use different schemes. Note that the digest/signature scheme is
separate and distinct from the NTP message digest used to construct
-the packet message authentication code (MAC). The only requirement
-is that the server private key and signature algorithm must match
-the public key and verification algorithm specified in the
-certificate.</p>
+the packet MAC. The only requirement is that the server sign key
+and signature algorithm must match the public key and verification
+algorithm specified in the certificate.</p>
+
+<h4>Autokey Dances</h4>
+
+<p>The Autokey protocol is somewhat intricate and a detailed
+explanation of the subprotocols, called dances, is beyond the scope
+of this page. Detailed information and briefings can be found via
+the NTP project page at <a href="html://www.ntp.org">
+www.ntp.org</a>. Briefly, the all dances start out with a client
+request for the server name and status word. The next step is to
+request the server host certificate and the third to request the
+certificate of the server that signed the first certificate. If the
+client verifies the server certificate signature, the server is
+pronounced authentic. The fourth step is to present a certificate
+to the server acting as certificate authority and request that it
+be signed and returned. This allows a client acting as a server for
+the next higher stratum to prove authenticity.</p>
+
+<p>The next steps retrieve the cryptographic values needed in the
+particular dance, including the cookie, autokey values and
+leapsecond table. As one of these steps the client presents the
+server with its certificate and asks that it be signed using the
+server private key. The server response is saved for future
+dependent clients as proof that the client itself is a legitimate
+member of the community and not an intruder attempting to
+impersonate a legitimate member.</p>
<h4>Key Management</h4>
files and optional sign key and leapseconds files. The symmetric
keys file is necessary for the <tt>ntpq</tt> and <tt>ntpdc</tt>
utility programs. The remaining files are necessary for the Autokey
-protocols to function. The files incorporate cryptographic values
-generated by the OpenSSL library algorithms and are in printable
-PEM-encoded ASCII format. Further information about these files and
-how they are generated and installed is on the <tt>ntp-genkeys</tt>
+protocol. The files incorporate cryptographic values generated by
+the OpenSSL library algorithms and are in printable PEM-encoded
+ASCII format. Further information about these files and how they
+are generated and installed is on the <tt>ntp-genkeys</tt>
page.</p>
<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. Since uniqueness is insured by the hostname
-and filestamp extensions in the file name, the files for a NFS
-server and dependent clients can all be installed in the same
-directory. This is different than the original Autokey version 1
-support, which required the private key to be installed separately
-for each client.</p>
+configuration command. Ordinarily, the host keys are permitted root
+read-only; the others are public values permitted world readable.
+Since uniqueness is insured by the hostname and file name
+extensions, the files for a NFS server and dependent clients can
+all be installed in the same directory. This is different than the
+original Autokey version 1 support, which required the private key
+to be installed separately for each client.</p>
<p>The recommended practice is to keep the file name extensions
when installing a file and to install a soft link from the default
automatically using the Autokey protocol.</p>
<p>Servers and peers 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 certificate and makes links from
-the default file names to the new file names. The <tt>ntpd</tt>
-daemon 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.</p>
+way. All machines have loaded the current keys and certificate at
+startup. At designated intervals, each machine generates a new
+public/private key pair and certificate and makes links from the
+default file names to the new file names. The <tt>ntpd</tt> daemon
+is restarted after each new generation and load the new files. 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. If for some reason this does not happen, the <tt>ntpd</tt>
+daemon refreshes all crhyptographic values at intervals of about
+one day, so that the protocol is restarted for all client
+associations and results in the same actions.</p>
<h4>Random Seed File</h4>
<p>All cryptographically sound key generation schemes must have
means to randomize the entropy seed used to initialize the internal
-random number generator of the library. It is important to
-understand that entropy must be evolved for each generation, for
-otherwise the random number sequence would be predictable. Various
-means dependent on external events, such as keystroke intervals,
-can be used to do this and some systems have built-in entropy
-sources. Suitable means are described in the OpenSSL software
-documentation, but are outside the scope of this page.</p>
+pseudo-random number generator used by the library routines. It is
+important to understand that entropy must be evolved for each
+generation, for otherwise the random number sequence would be
+predictable. Various means dependent on external events, such as
+keystroke intervals, can be used to do this and some systems have
+built-in entropy sources. Suitable means are described in the
+OpenSSL software documentation, but are outside the scope of this
+page.</p>
<p>The entropy seed used by the OpenSSL library is contained in a
file, usually called <tt>.rnd</tt>, which must be available when
starting the NTP daemon or the <tt>ntp-genkeys</tt> program. The
NTP daemon will first look for the file using the path specified by
-the <tt>random</tt> subcommand of the <tt>crypto</tt> command. If
+the <tt>randfile</tt> subcommand of the <tt>crypto</tt> command. If
not specified in this way, or when starting the <tt>
ntp-genkeys</tt> program, the OpenSSL library will look for the
file using the path specified by the <tt>RANDFILE</tt> environment
variable in the user home directory, whether root or some other
user. If the <tt>RANDFILE</tt> environment variable is not present,
the library will look for the <tt>.rnd</tt> file in the user home
-directory. Alternatively, the location can be specified by the <tt>
-randfile</tt> keyword of the <tt>crypto</tt> configuration command.
-If the file is not available or cannot be written, the daemon exits
-with a message to the system log and the <tt>ntp-genkeys</tt>
-program exits with a suitable error message.</p>
+directory. If the file is not available or cannot be written, the
+daemon exits with a message to the system log and the <tt>
+ntp-genkeys</tt> program exits with a suitable error message.</p>
<p>The daemon will occasionally add additional entropy and write to
-the file when computing a Diffie-Hellman agreement value, for
-example, so the file must be writable by root. If the <tt>
-ntp-genkeys</tt> program is run by other than root, or if the Unix
-<tt>su</tt> command is used to assume root, the home directory
-assumed by the OpenSSL library might not be root. Probably the
-safest way to generate keys is to log in as root, change to the
-keys directory and run the <tt>ntp-genkeys</tt> program from
-there</p>
+the file when generating new keys and certificates, for example, so
+the file must be writable by root. If the <tt>ntp-genkeys</tt>
+program is run by other than root, or if the Unix <tt>su</tt>
+command is used to assume root, the home directory assumed by the
+OpenSSL library might not be root. Probably the safest way to
+generate keys is to log in as root, change to the keys directory
+and run the <tt>ntp-genkeys</tt> program from there</p>
<h4>Authentication Commands</h4>
monitoring protocol trap mechanism.</p>
<dl>
-<dt>101 (bad field length)</dt>
+<dt>101 (bad field format or length)</dt>
<dd>The packet has invalid version, length or format.</dd>
received. This could be due to a replay or a key file generation
error.</dd>
-<dt>104 (bad public key)</dt>
+<dt>104 (bad or missing public key)</dt>
<dd>The public key is missing, has incorrect format or is an
unsupported type.</dd>
<dd>The message fails the signature check. It could be bogus or
signed by a different private key.</dd>
-<dt>109 (subject hostname mismatch)</dt>
+<dt>109 (certificate not verified)</dt>
-<dd>The host name is invalid or does not match the subject name in
-the certificate.</dd>
+<dd>The certificate is invalid or signed with the wrong key.</dd>
-<dt>110 (time not verified)</dt>
+<dt>110 (certificate expired)</dt>
<dd>The certificate is not yet valid or has expired.</dd>
-<dt>111 (bad cookie encrypt)</dt>
+<dt>111 (bad or missing cookie)</dt>
<dd>The cookie is corrupted or bogus.</dd>
-<dt>112 (bad TAI data)</dt>
+<dt>112 (bad or missing leapseconds table)</dt>
-<dd>The leapseconds file is currupted or bogus.</dd>
+<dd>The leapseconds file is corrupted or bogus.</dd>
+
+<dt>113 (bad or missing certificate)</dt>
+
+<dd>The server does not have the requested certificate.</dd>
</dl>
<h4>Files</h4>
<p>See the <a href="genkeys.htm"><tt>ntp-genkeys</tt></a> page.</p>
-<h4>Bugs</h4>
-
-<p>The mysterious Digital Signature Algorithm (DSA) in the OpenSSL
-library should be conquered and provisioned.</p>
-
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" &lt;html>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" &amp;lt;html>
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
significantly due to the individual service providers.</p>
<p>The community served by the synchronization protocol can be very
-large. For instance, the NTP community in the Internet of 1998
-includes over 230 primary time servers, synchronized by radio,
+large. For instance, the NTP community in the Internet of 2002 includes over 230 primary time servers, synchronized by radio,
satellite and modem, and well over 100,000 secondary servers and
clients. In addition, there are many thousands of private
communities in large government, corporate and institution
<p>Running the program as other than root and using the Unix <tt>
su</tt> command to assume root may not work properly, since by
-default the OpenSSL library looks for the random seed file in the
-user home directory. However, installing the keys as root might not
-work in NFS-mounted file systems, as NFS clients may not be able to
-write to the shared keys directory, even as root. NFS clients
-should run the program as root or some other user and save the key
-files in a writable directory that can be read directly or
-indirectly by the NFS server. The NFS server can then copy them to
-the shared keys directory. Since the <tt>ntp-genkeys</tt> program
-does not write the random seed file, it is convenient to define the
-<tt>$RANDFILE</tt> environment variable used by the OpenSSL library
-as the path to the random seed file.</p>
+default the OpenSSL library looks for the random seed file <tt>
+.rnd</tt> in the user home directory. However, there should be only
+one <tt>.rnd</tt>, most conveniently in the root directory, so it
+is convenient to define the <tt>$RANDFILE</tt> environment variable
+used by the OpenSSL library as the path to <tt>/.rnd.</tt></p>
+
+<p>Installing the keys as root might not work in NFS-mounted shared
+file systems, as NFS clients may not be able to write to the shared
+keys directory, even as root. In this case, NFS clients can specify
+the files in another directory such as <tt>/etc</tt> using the <tt>
+keysdir</tt> command. There is no need for one client to read the
+keys and certificates of another client or the server, as these
+values are obtained by the Autokey protocol during operation.</p>
<h4>File Naming Conventions</h4>
process. The reader is referred to the OpenSSL documentation for
further details.</p>
-<p>The <tt>ntp-genkeys</tt> program generates a X.509 public
-certificate request in a file named <tt>
-ntpkey_<i>digestname</i>req_<i>hostname</i>.<i>filestamp</i></tt>,
+<p>The <tt>ntp-genkeys</tt> program generates a X.509 Version 3
+public certificate in a file named <tt>
+ntpkey_<i>digestname</i>cert_<i>hostname</i>.<i>filestamp</i></tt>,
where <i>digestname</i> is the name of the digest/signature scheme.
-This file is not used by the current Autokey version, but might be
-useful in related applications. The file contains only public
-values and can be freely transmitted and stored anywhere without
-further cryptographic protection. The NTP daemon expects this file
-with name <tt>ntpkey_req_<i>hostname</i></tt>, so a soft link is
-needed to direct this name to the particular file name generated.
-Where security considerations require, this file can be transmitted
-to a trusted certificate authority (CA) and returned as a signed
-public certificate for use in the Autokey protocol.</p>
-
-<p>For convenience, the <tt>ntp-genkeys</tt> program also generates
-a self-signed X.509 public certificate in a file named <tt>
-ntpkey_<i>digestname</i>cert_<i>hostname</i>.<i>filestamp</i></tt>.
The file contains only public values and can be freely transmitted
and stored anywhere without further cryptographic protection. The
NTP daemon expects this file with name <tt>
ntpkey_cert_<i>hostname</i></tt>, so a soft link is needed to
-direct this name to the particular file name used. This file can be
-used in lieu of a CA certificate and has compatible encoding and
-content.</p>
+direct this name to the particular file name generated. The Autokey
+protocol includes provisions to retrieve the server certificate and
+to have the server sign and return the client certificate. Where
+security considerations require, certificates can be transmitted to
+a trusted certificate authority (CA) and returned as a signed
+public certificate for use in the Autokey protocol.</p>
<p>The Autokey protocol supports all digest/signature schemes
available in the OpenSSL library, including those using the MD2,
<li><a href="exec.htm">Executive Summary - Computer Network Time
Synchronization</a></li>
+<li><a href="y2k.htm">The Network Time Protocol Timescale and Era
+Numbering</a></li>
+
<li><a href="biblio.htm">Protocol Conformance Statement</a></li>
<li><a href="leap.htm">NTP Timescale and Leap Seconds</a></li>
The manycast paradigm is designed to find a plurality of redundant
servers satisfying defined optimality criteria.</p>
-<p>Manycasting requires public key cryptography, which in NTPv4 is
-provided by the OpenSSL cryptographic library available from <a
-href="http://www.openssl.org">http://www.openssl.org</a>. The
-library can also be used with other NTPv4 modes as well and this is
-highly recommended, especially for broadcast modes.</p>
-
-<p>A persistent manycast client association is configured using a
-<tt>manycastclient</tt> command, which is similar to a <tt>
+<p>Manycasting can be used with either symmetric key or public key
+cryptography. The public key infrastructure (PKI) offers the best
+protection against compromised keys and is generally considered
+stronger, at least with relatively large key sizes. It is
+implemented using the Autokey protocol and the OpenSSL
+cryptographic library available from <a href=
+"http://www.openssl.org">http://www.openssl.org</a>. The library
+can also be used with other NTPv4 modes as well and is highly
+recommended, especially for broadcast modes.</p>
+
+<p>A persistent manycast client association is configured using the
+<tt>manycastclient</tt> command, which is similar to the <tt>
server</tt> command but with a multicast (class D) group address
instead of an ordinary IP (class A, B, C) address. When more
servers are needed, it broadcasts manycast client messages to this
address at the minimum feasible rate and minimum feasible
time-to-live (TTL) 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
+different group address, each one serving as a template for a
future ephemeral unicast client/server association.</p>
<p>Manycast servers configured with the <tt>manycastserver</tt>
ephemeral client/server association according to the matching
manycast client template, but only if cryptographically
authenticated and the server stratum is less than or equal to the
-client stratum. 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"
-associations according to stratum and synchronization distance. The
-surviving associations then continue in ordinary client/server
-mode.</p>
+client stratum. Authentication is explicitly required and either
+symmetric key or public key (Autokey) can be used. 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" associations according to stratum and
+synchronization distance. The surviving associations then continue
+in ordinary client/server mode.</p>
<p>The manycast client polling strategy is designed to reduce as
much as possible the volume of manycast client messages and the
continuously and run either <tt>ntpdate</tt> or <tt>ntpd -q</tt> as
a cron job. In either case the servers must be configured in
advance and the program fails if none are available when the cron
-job runs. A really slick application of Manycast is with <tt>ntp
+job runs. A really slick application of manycast is with <tt>ntp
-q</tt>. The program wakes up, scans the local landscape looking
for the usual suspects, selects the best from among the rascals,
sets the clock and then departs. Servers do not have to be
configured in advance and all clients throughout the network can
have the same configuration file.</p>
+<h3>Manycast Interactions with Autokey</h3>
+
+<p>Each time a manycast client sends a client mode packet to a
+multicast group address, all manycast servers in scope generate a
+reply including the host name and status word. The manycast clients
+then run the Autokey protocol, which collects and verifies all
+certificates involved. Following the burst interval all but three
+survivors are cast off, but the certificates remain in the local
+cache. It often happens that several complete signing trails from
+the client to the primary servers are collected in this way.</p>
+
+<p>About once an hour or less often if the poll interval exceeds
+this, the client regenerates the Autokey key list. This is in
+general transparent in client/server mode. However, about once per
+day the server private value used to generate cookies is refreshed
+along with all manycast client associations. In this case all
+cryptographic values including certificates is refreshed. If a new
+certificate has been generated since the last refresh epoch, it
+will automatically revoke all prior certificates that happen to be
+in the certificate cache. At the same time, the manycast scheme
+starts all over from the beginning and the expanding ring shrinks
+to the minimum and increments from there while collecting all
+servers in scope.</p>
+
<h3>Manycast Options</h3>
<dl>
line of the following form to the current element of a file
generation set named <tt>peerstats</tt>:</dd>
-<dd><tt>48773 10847.650 127.127.4.1 9714 -0.001605 0.00000
-0.00142</tt></dd>
+<dd><tt>48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000
+0.001424877 0.000958674</tt></dd>
<dd>The first two fields show the date (Modified Julian Day) and
time (seconds and fraction past UTC midnight). The next two fields
show the peer address in dotted-quad notation and status,
respectively. The status field is encoded in hex in the format
described in Appendix A of the NTP specification RFC 1305. The
-final three fields show the offset, delay and RMS jitter, all in
-seconds.</dd>
+final four fields show the offset, delay, dispersion and RMS
+jitter, all in seconds.</dd>
<dt><tt>rawstats</tt></dt>
projects / thirdparty / ntp.git / commitdiff
