-<HTML><HEAD><TITLE>
+<html><head><title>
Authentication Options
-</TITLE></HEAD><BODY><H3>
+</title></head><body><h3>
Authentication Options
-</H3><HR>
+</h3><hr>
<H4>Authentication Support</H4>
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) operating in Cipher Block Chaining (CBC) mode, commonly called DES-CBC.
-Subsequently, this was augmented by the RSA Message Digest 5 (MD5) 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. NTPv4 retains this scheme and,
-in addition, provides a new <I>autokey </I>scheme based on reverse hashing
-and public key cryptography. Authentication can be 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.
+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) operating in Cipher Block Chaining (CBC) mode,
+commonly called DES-CBC. Subsequently, this was augmented by the RSA
+Message Digest 5 (MD5) 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 and, in addition, provides a new
+<I>autokey</I> scheme based on reverse hashing and public key
+cryptography. Authentication can be 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.
<P>The authentication options specify the suite of keys, select the key
for each configured association and manage the configuration operations,
-as described below. The <TT>auth</TT> flag which controls these functions
-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 set, persistent peer
-associations and remote configuration commands are effective only if cryptographically
-authenticated. 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 operations.
-
-<P>The <TT>auth</TT> flag affects all authentication procedures described
-below; however, it operates differently if cryptographic support is compiled
-in the distribution. If this support is available and the flag is enabled,
-then persistent associations are mobilized and remote configuration commands
-are effective only if successfully authenticated. If the support is unavailable
-and the flag is enabled, then it is not possible under any conditions to
-mobilize persistent associations or respond to remote configuration commands.
-The <TT>auth </TT>flag normally defaults to set if cryptographic support
-is available and to reset otherwise.
-
-<P>With the above vulnerabilities in mind, it is desirable to set the auth
-flag in all cases. One aspect which is often confusing is the name resolution
-process which maps server names in the configuration file to IP addresses.
-In order to protect against bogus name server messages, this process is
-authenticated using an internally generated key which is normally invisible
-to the user. However, if cryptographic support is unavailable and the <TT>auth</TT>
-flag is enabled, 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 leaving the flag disabled and enabling it once the name
-resolution process is complete.
-<H4>
-Private Key Scheme</H4>
-The original RFC-1305 specification allows any one of possibly 65,536 keys,
-each distinguished 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.key</TT>s, 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 ones can be used
-as passwords for the <TT><A HREF="ntpq.htm">ntpq</A></TT> and <TT><A HREF="ntpdc.htm">ntpdc</A></TT>
+as described below. The <TT>auth</TT> flag which controls these
+functions 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 set, persistent peer associations and remote configuration
+commands are effective only if cryptographically authenticated. 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>The <TT>auth</TT> flag affects all authentication procedures
+described below; however, it operates differently if cryptographic
+support is compiled in the distribution. If this support is available
+and the flag is enabled, then persistent associations are mobilized and
+remote configuration commands are effective only if successfully
+authenticated. If the support is unavailable and the flag is enabled,
+then it is not possible under any conditions to mobilize persistent
+associations or respond to remote configuration commands. The
+<TT>auth</TT> flag normally defaults to set if cryptographic support is
+available and to reset otherwise.
+
+<P>With the above vulnerabilities in mind, it is desirable to set the
+<tt>auth</TT> flag in all cases. One aspect which is often confusing is
+the name resolution process which maps server names in the configuration
+file to IP addresses. In order to protect against bogus name server
+messages, this process is authenticated using an internally generated
+key which is normally invisible to the user. However, if cryptographic
+support is unavailable and the <TT>auth</TT> flag is enabled, 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 leaving the flag disabled and enabling it once the name resolution
+process is complete.
+
+<H4>Private Key Scheme</H4>
+The original RFC-1305 specification allows any one of possibly 65,534
+keys, each distinguished 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 ones 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 and installs
-the keys in the key cache. However, the keys must be activated before they
-can be used with the <TT>trusted </TT>command. This allows, for instance,
-the installation of possibly several batches of keys and then activating
-or inactivating 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 the <TT>ntpq </TT>utility.
-<H4>
-Autokey Scheme</H4>
+<P>When <TT>ntpd</TT> is first started, it reads the key file and
+installs the keys in the key cache. However, the keys must be activated
+before they can be used with the <TT>trusted</TT> command. 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 the <TT>ntpq</TT> utility.
+
+<H4>Autokey Schemes</H4>
+
The original NTPv3 authentication scheme described in RFC-1305 continues
-to be supported. In NTPv4, an additional authentication scheme called <I>autokey
-</I>is available. It operates much like the S-KEY scheme, in that a session
-key list is constructed and the entries used in reverse order. A description
-of the scheme, along with a comprehensive security analysis, is contained
-in a technical report available from the IETF web page <A HREF="www.ietf.org">www.ietf.org</A>
-.
-
-<P>The autokey scheme is specifically designed for multicast modes, where
-clients normally do not send messages to the server. In these modes, the
-server uses the scheme to generate a key list by repeated hashing of a
-secret value. The list is used in reverse order to generate a unique session
-key for each message sent. The client regenerates the session key and verifies
-the hash matches the previous session key. Each message contains the public
-values binding the session key to the secret value, but these values need
-to be verified only when the server generates a new key list or more than
-four server messages have been lost.
-
-<P>The scheme is appropriate for client/server and symmetric-peer modes
-as well. In these modes, the client generates a session key as in multicast
-modes. The server regenerates the session key and uses it to formulates
-a reply using its own public values. The client verifies the key identifier
-of the reply matches the request, verifies the public values and validates
-the message. In peer mode, each peer independently generates a key list
-and operates as in the multicast mode.
-
-<P>The autokey scheme requires no change to the NTP packet header format
-or message authentication code (MAC), which is appended to the header;
-however, if autokey is in use, an extensions field is inserted between
-the header and MAC. The extensions field contains a random public value
-which is updated at intervals specified by the revoke command, together
-with related cryptographic values used in the signing algorithm. The format
-of the extensions field is defined in Internet Draft draft-NTP- auth-coexist-00.txt.
-The MAC itself is constructed in the same way as NTPv3, but using the original
-NTP header and the extensions field padded to a 64-bit boundary. Each new
-public value is encrypted by the host private value. It is the intent of
-the design, not yet finalized, that the public value, encrypted public
-value, public key and certificate be embedded in the extensions field where
-the client can decrypt as needed. However, the relatively expensive encryption
-and decryption operations are necessary only when the public value is changed.
-
-<P>Note that both the original NTPv3 authentication scheme and the new
-NTPv4 autokey scheme operate separately for each configured association,
-so there may be several session key lists operating independently at the
-same time. Since all keys, including session keys, occupy the same key
-cache, provisions have been made to avoid collisions, where some random
-roll happens to collide with another already generated. Since something
-like four billion different session key identifiers are available, the
-chances are small that this might happen. If it happens during generation,
-the generator terminates the current session key list. By the time the
-next list is generated, the collided key will probably have been expired
-or revoked.
-
-<P>While permanent keys have lifetimes that expire only when manually revoked,
-random session keys have a lifetime specified at the time of generation.
-When generating a key list for an association, the lifetime of each key
-is set to expire one poll interval later than it is scheduled to be used.
-The maximum lifetime of any key in the list is specified by the <TT>autokey</TT>
-command. Lifetime enforcement is a backup to the normal procedure that
-revokes the last-used key at the time the next key on the key list is used.
-<H4>
-Authentication Commands</H4>
+to be supported. In NTPv4 an additional authentication scheme called
+<I>autokey</I> is available. It has several modes of operation
+corresponding to the various NTP modes supported. Broadcast/multicast
+mode uses a variant of the S-KEY scheme, in which a pseudo-random key
+list is generated and used in the reverse order. Client/server mode uses
+a similar scheme together with a special cookie which can be computed
+separately by the client and server. Symmetric mode uses the
+Diffie-Hellman algorithm and the Station-to-Station key agreement
+protocol. RSA public signatures are used in all modes to verify the
+source. The scheme is described along with an executive summary, current
+status, briefing slides and reading list, at
+www.eecis.udel.edu/~mills/autokey.htm.
+
+<p>The cryptographic values used by the <tt>autokey</tt> scheme are
+incorporated as a set of four files generated by the <a
+href=genkeys.htm><tt>ntp_genkeys</tt></a> program, including the DES/MD5
+private keys, RSA public/private key pair, and the parameters for the
+Diffie-Hellman key-agreement algorithm. See the <tt>ntp_genkeys</tt>
+page for a description of the format and use of these files. They
+contain cryptographic values generated by the algorithms of the
+<tt>rsaref20</tt> package and are in printable ASCII format. Since the
+algorythms are seeded by the system clock, each run of this program will
+produce a different outcome.
+
+<p>The <tt>ntp.keys</tt> file contains the private MD5 keys. It must be
+distributed by secure means to other servers and clients sharing the
+same security compartment and made visible only to root. 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. The
+<tt>ntp_dh</tt> file contains the parameters for the Diffie-Hellman key
+agreement algorithm. It is necessary that all servers and clients of a
+security compartment share a single <tt>ntp_dh</tt> file, but it does
+not matter which one. This file can 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 DNS name of the host that generated
+it. Each server and client sharing a NTP association must have the
+<tt>ntpkey_<i>host</i></tt> file for itself and its associate, with the
+exception of broadcast servers, which do not authenticate the clients..
+These files can be widely distributed and stored using insecure means,
+since the data are public values.
+
+<p>Public keys can be attached to associations in three ways. For
+configured associations the default public key file name is formed from
+the prefix "ntpkey_" concatenated with the canonical host name found
+during the DNS name resolution process. Alternately, the file name can
+be specified using the <tt>publickey</tt> argument to the
+<tt>server</tt> or <tt>peer</tt> configuration commands. If for some
+reason the file cannot be found, the daemon can request the public key
+directly from its peer, but only if enabled by the special file name
+"peer".
+
+<H4>Authentication Commands</H4>
<DL>
-<DT>
-<TT>keys <I>keyfile</I></TT></DT>
-
-<DD>
-Specifies the file name containing the encryption keys and key identifiers
-used by <TT>ntpd</TT>, <TT>ntpq</TT> and <TT>ntpdc</TT> when operating
-in authenticated mode. The format of this file is described later in this
-document.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>trustedkey <I>key</I> [...]</TT></DT>
-
-<DD>
-Specifies the encryption key identifiers which are trusted for the purposes
-of authenticating peers suitable for synchronization, 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 <I><TT>key</TT></I> arguments are 32-bit unsigned integers
-with values less than 65,536. Note that NTP key 0 is used to indicate an
-invalid key and/or key identifier, so should not be used for any other
-purpose.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>requestkey <I>key</I></TT></DT>
-
-<DD>
-Specifies the key identifier to use with the <TT>ntpdc</TT> program, which
-uses a proprietary protocol specific to this implementation of <TT>ntpd</TT>.
-This program is useful to diagnose and repair problems that affect <TT>ntpd</TT>
-operation. The <I><TT>key</TT></I> argument to this command is a 32-bit
-key identifier for a previously defined trusted key. If no <TT>requestkey
-</TT>command is included in the configuration file, or if the keys don't
-match, any request to change a server variable with be denied.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>controlkey <I>key</I></TT></DT>
-
-<DD>
-Specifies the key identifier to use with the <TT>ntpq</TT> program, which
-uses the standard protocol defined in RFC-1305. This program is useful
-to diagnose and repair problems that affect <TT>ntpd</TT> operation. The
-<I><TT>key</TT></I> argument to this command is a 32-bit key identifier
-for a trusted key in the key cache. If no <TT>controlkey </TT>command is
-included in the configuration file, or if the keys don't match, any request
-to change a server variable with be denied.</DD>
+
+<dt><tt>autokey [<i>logsec</i>]</tt>
+<dd>Specifies the interval between regenerations of the session key list
+used with the autokey feature. 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 <TT>ntpq</TT> program,
+which uses the standard protocol defined in RFC-1305. This program is
+useful to diagnose and repair problems that affect <TT>ntpd</TT>
+operation. The <TT><I>key</I></TT> argument to this command is a key
+identifier for a trusted key, where the value can be in the range 1 to
+65534, inclusive. If no <TT>controlkey</TT> command present in the
+configuration file, or if the keys disagree, any request to change a
+server variable with be denied.</DD>
+
+<DT><TT>crypto [privatekey <i>file</i>] [publickey <i>file</i>] [dhparms
+<i>file</i>] </TT></DT>
+<DD>This command requires the NTP daemon build process be configured
+with the RSA library. The presence of this command causes the daemon to
+load the host RSA private key file, public key file and Diffie-Hellman
+parameter file. If one or more files are left unspecified, the default
+names are used as described above.</DD>
+
+<DT><TT>keys <I>keyfile</I></TT></DT>
+<DD>Specifies the file name containing the private encryption keys and
+key identifiers used by <TT>ntpd</TT>, <TT>ntpq</TT> and <TT>ntpdc</TT>
+when operating in authenticated mode. The format of this file is
+described later in this document.</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 directory path for the private
+key file, 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 <TT>ntpdc</TT> utility
+program, which uses a proprietary protocol specific to this
+implementation of <TT>ntpd</TT>. This program is useful to diagnose and
+repair problems that affect <TT>ntpd</TT> operation. The
+<TT><I>key</I></TT> argument to this command is a key identifier for a
+trusted key, where the value can be in the range 1 to 65534, inclusive.
+If no <TT>requestkey</TT> command present in the configuration file, or
+if the keys disagree, any request to change a server variable with be
+denied.</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
+12 (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 encryption key identifiers which are trusted for the
+purposes of authenticating peers suitable for synchronization, 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. Note that NTP key 0 is used to indicate an invalid key
+and/or key identifier, so should not be used for any other purpose.</DD>
+
</DL>
-<H4>
-Authentication Key File Format</H4>
+<H4>Authentication Key File Format</H4>
+
In the case of DES, the keys are 56 bits long with, depending on type,
a parity check on each byte. In the case of MD5, the keys are 64 bits (8
-bytes). <TT>ntpd</TT> reads its keys from a file specified using the <TT>-k</TT>
-command line option or the <TT>keys</TT> statement in the configuration
-file. While key number 0 is fixed by the NTP standard (as 56 zero bits)
-and may not be changed, one or more of the keys numbered 1 through 15 may
-be arbitrarily set in the keys file.
+bytes). <TT>ntpd</TT> reads its keys from a file specified using the
+<TT>-k</TT> command line option or the <TT>keys</TT> statement in the
+configuration file. While key number 0 is fixed by the NTP standard (as
+56 zero bits) and may not be changed, one or more of the keys numbered 1
+through 15 may be arbitrarily set in the keys file.
<P>The key file uses the same comment conventions as the configuration
file. Key entries use a fixed format of the form
<P><I><TT>keyno type key</TT></I>
-<P>where <I><TT>keyno</TT></I> is a positive integer, <I><TT>type</TT></I>
-is a single character which defines the key format, and <I><TT>key</TT></I>
-is the key itself.
+<P>where <I><TT>keyno</TT></I> is a positive integer,
+<I><TT>type</TT></I> is a single character which defines the key format,
+and <I><TT>key</TT></I> is the key itself.
<P>The key may be given in one of three different formats, controlled by
-the <I><TT>type</TT></I> character. The three key types, and corresponding
-formats, are listed following.
+the <I><TT>type</TT></I> character. The three key types, and
+corresponding formats, are listed following.
+
<DL>
-<DT>
-<TT>S</TT></DT>
-
-<DD>
-The key is a 64-bit hexadecimal number in the format specified in the DES
-specification; that is, the high order seven bits of each octet are used
-to form the 56-bit key while the low order bit of each octet is given a
-value such that odd parity is maintained for the octet. Leading zeroes
-must be specified (i.e., the key must be exactly 16 hex digits long) and
-odd parity must be maintained. Hence a zero key, in standard format, would
-be given as <TT>0101010101010101</TT>.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>N</TT></DT>
-
-<DD>
-The key is a 64-bit hexadecimal number in the format specified in the NTP
-standard. This is the same as the DES format, except the bits in each octet
-have been rotated one bit right so that the parity bit is now the high
-order bit of the octet. Leading zeroes must be specified and odd parity
-must be maintained. A zero key in NTP format would be specified as <TT>8080808080808080</TT>.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>A</TT></DT>
-
-<DD>
-The key is a 1-to-8 character ASCII string. A key is formed from this by
-using the low order 7 bits of each ASCII character in the string, with
-zeroes added on the right when necessary to form a full width 56-bit key,
-in the same way that encryption keys are formed from Unix passwords.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>M</TT></DT>
-
-<DD>
-The key is a 1-to-8 character ASCII string, using the MD5 authentication
-scheme. Note that both the keys and the authentication schemes (DES or
-MD5) must be identical between a set of peers sharing the same key number.</DD>
+
+<DT><TT>S</TT></DT>
+<DD>The key is a 64-bit hexadecimal number in the format specified in
+the DES specification; that is, the high order seven bits of each octet
+are used to form the 56-bit key while the low order bit of each octet is
+given a value such that odd parity is maintained for the octet. Leading
+zeroes must be specified (i.e., the key must be exactly 16 hex digits
+long) and odd parity must be maintained. Hence a zero key, in standard
+format, would be given as <TT>0101010101010101</TT>.</DD>
+
+<DT><TT>N</TT></DT>
+<DD>The key is a 64-bit hexadecimal number in the format specified in
+the NTP standard. This is the same as the DES format, except the bits in
+each octet have been rotated one bit right so that the parity bit is now
+the high order bit of the octet. Leading zeroes must be specified and
+odd parity must be maintained. A zero key in NTP format would be
+specified as <TT>8080808080808080</TT>.</DD>
+
+<DT><TT>A</TT></DT>
+<DD>The key is a 1-to-8 character ASCII string. A key is formed from
+this by using the low order 7 bits of each ASCII character in the
+string, with zeroes added on the right when necessary to form a full
+width 56-bit key, in the same way that encryption keys are formed from
+Unix passwords.</DD>
+
+<DT><TT>M</TT></DT>
+<DD>The key is a 1-to-8 character ASCII string, using the MD5
+authentication scheme. Note that both the keys and the authentication
+schemes (DES or MD5) must be identical between a set of peers sharing
+the same key number.</DD>
+
</DL>
-Note that the keys used by the <TT>ntpq</TT> and <TT>ntpdc</TT> programs
-are checked against passwords requested by the programs and entered by
-hand, so it is generally appropriate to specify these keys in ASCII format.
-<HR>
-<ADDRESS>
-David L. Mills (mills@udel.edu)</ADDRESS>
-
-</BODY>
-</HTML>
+
+<p>Note that the keys used by the <TT>ntpq</TT> and <TT>ntpdc</TT>
+programs are checked against passwords requested by the programs and
+entered by hand, so it is generally appropriate to specify these keys in
+ASCII format.
+
+<h4>Files</h4>
+
+<tt>ntp.keys</tt> private MD5 keys
+<br><tt>ntpkey</tt> RSA private key
+<br><tt>ntpkey_<i>host</i></tt> RSA public key
+<br><tt>ntp_dh</tt> Diffie-Hellman parameters
+
+<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.
+
+<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>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 operands. 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,
-while autokey and burst modes are supported by these commands,
+<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>
+or even destructive.
+
+<dl>
+
+<dt><tt>peer <i>address</i> [key <i>key</i> | autokey | publickey
+<i>keyfile</i>] [burst] [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 | publickey
+<i>keyfile</i>] [burst] [version <i>version</i>] [prefer] [minpoll
+<i>minpoll</i>] [maxpoll <i>maxpoll</i>] [publickey
+<i>keyfile</i>]</tt></dt>
+
+<p><dt><tt>broadcast <i>address</i> [key <i>key</i> | autokey] [burst]
+[version <i>version</i>] [minpoll <i>minpoll</i>] [maxpoll
+<i>maxpoll</i>] [ttl <i>ttl</i>]</tt></dt>
+
+<p><dt><tt>manycastclient <i>address</i> [key <i>key</i> | autokey |
+publickey <i>keyfile</i>] [burst] [version <i>version</i>] [minpoll
+<i>minpoll</i> [maxpoll <i>maxpoll</i>] [ttl <i>ttl</i>] [publickey
+<i>file</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>
+
+<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>
+
+<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>
+
+<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>
+
+<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 server 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>
+
+<dd>Options</dd>
+
+<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>
+<dt><tt>burst</tt></dt>
+<dd>At each poll interval, send a burst of eight packets spaced, instead
+of the usual one.</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>
+
+<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>
+
+<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>
+
+<DT><TT>publickey <I>file</I></TT></DT>
+<DD>This command requires the NTP daemon build process be configured
+with the RSA library. The command specifies the name of the public key
+file for the server or peer. The default name for this file is
+<tt>ntpkey_<i>host</i></tt>, where <i>host</i> is the DNS canonical name
+of the server or peer. See the <a href=authopt.htm>Authentication
+Options</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>
+
+<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>
+
+</dl></dd></dl></dd>
+
+<h4>Auxilliary Commands</h4>
<dl>
- <dt><tt>peer </tt><i><tt>address</tt></i><tt> [autokey | key </tt><i><tt>key</tt></i><tt>]
- [burst] [version </tt><i><tt>version</tt></i><tt>]
- [prefer] [minpoll </tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt>
- </tt></i><tt>[maxpoll </tt><i><tt>maxpoll</tt></i><tt>]</tt></dt>
- <dd> </dd>
- <dt><tt>server </tt><i><tt>address</tt></i><tt> [autokey |
- key </tt><i><tt>key</tt></i><tt>] [burst] [version </tt><i><tt>version</tt></i><tt>]
- [prefer] [minpoll </tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt>
- </tt></i><tt>[maxpoll </tt><i><tt>maxpoll</tt></i><tt>]</tt></dt>
- <dd> </dd>
- <dt><tt>broadcast </tt><i><tt>address</tt></i><tt> [autokey |
- key </tt><i><tt>key</tt></i><tt>] [burst] [version </tt><i><tt>version</tt></i><tt>]
- [minpoll </tt><i><tt>minpoll</tt></i><tt>]</tt><i><tt> </tt></i><tt>[maxpoll
- </tt><i><tt>maxpoll</tt></i><tt>] [ttl </tt><i><tt>ttl</tt></i><tt>]</tt></dt>
- <dd> </dd>
- <dt><tt>manycastclient </tt><i><tt>address</tt></i><tt>
- [autokey | key </tt><i><tt>key</tt></i><tt>] [burst]
- [version </tt><i><tt>version</tt></i><tt>] [minpoll </tt><i><tt>minpoll
- </tt></i><tt>[maxpoll </tt><i><tt>maxpoll</tt></i><tt>]
- [ttl </tt><i><tt>ttl</tt></i><tt>]</tt></dt>
- <dd> </dd>
- <dd>These four commands specify the time server name or
- address to be used and the mode in which to operate. The <i><tt>address</tt></i><tt>
- </tt>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> </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> </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 b, m or r
- addresses.</dd>
- <dd> </dd>
- <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> </dd>
- <dt><tt>broadcast</tt></dt>
- <dd>For type b and m addresses (only), this is
- 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>
- <dd> </dd>
- <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> </dd>
- <dt><tt>manycastclient</tt> </dt>
- <dd>For type m 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>
- <dd> </dd>
- <dd>The <tt>manycast </tt>command specifies that the
- local server is to operate in client mode with
- the remote server 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> </dd>
- </dl>
- </dd>
- <dd>Options</dd>
- <dd> </dd>
- <dd><dl>
- <dt><tt>autokey</tt></dt>
- <dd>All packets sent to the address are to include
- authentication fields encrypted using the autokey
- scheme.</dd>
- <dd> </dd>
- <dt><tt>burst</tt></dt>
- <dd>At each poll interval, send a burst of eight
- packets spaced, instead of the usual one.</dd>
- <dd> </dd>
- <dt><tt>key </tt><i><tt>key</tt></i></dt>
- <dd>All packets sent to the address are to include
- authentication fields encrypted using the
- specified <i>key</i> identifier, which is an
- unsigned 32-bit integer less than 65536. The
- default is to include no encryption field.</dd>
- <dd> </dd>
- <dt><tt>version </tt><i><tt>version</tt></i></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> </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> </dd>
- <dt><tt>ttl </tt><i><tt>ttl</tt></i></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> </dd>
- <dt><tt>minpoll </tt><i><tt>minpoll</tt></i></dt>
- <dt><tt>maxpoll </tt><i><tt>maxpoll</tt></i></dt>
- <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> </dd>
- </dl>
- </dd>
- <dt><tt>broadcastclient</tt></dt>
- <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> </dd>
- <dt><tt>multicastclient [</tt><i><tt>address</tt></i><tt>]
- [...]</tt></dt>
- <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 a
- multicast kernel.</dd>
- <dd> </dd>
- <dt><tt>driftfile </tt><i><tt>driftfile</tt></i></dt>
- <dd>This command specifies the name of the file used to
- record the frequency offset of the local clock
- oscillator. If the file exists, it is read at startup in
- order to set the initial frequency offset and then
- updated once per hour with the current frequency offset
- computed by the daemon. If the file does not exist or
- this command is not given, the initial frequency offset
- is assumed zero. In this case, it may take some hours for
- the frequency to stabilize and the residual timing errors
- to subside.</dd>
- <dd> </dd>
- <dd>The file format consists of a single line containing a
- single floating point number, which records the frequency
- offset measured in parts-per-million (PPM). The file is
- updated by first writing the current drift value into a
- temporary file and then renaming this file to replace the
- old version. This implies that <tt>ntpd</tt> must have
- write permission for the directory the drift file is
- located in, and that file system links, symbolic or
- otherwise, should be avoided.</dd>
- <dd> </dd>
- <dt><tt>manycastserver </tt><i><tt>address </tt></i><tt>[...]</tt></dt>
- <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> </dd>
- <dt><tt>revoke [</tt><i><tt>logsec</tt></i><tt>]</tt> </dt>
- <dd>Specifies the interval between recomputations of the
- private value used with the autokey feature, which
- ordinarily requires an expensive public- key computation.
- The default value is 12 (65,536 s or about 18 hours). For
- poll intervals above the specified interval, a new
- private value will be recomputed for every message sent.</dd>
- <dd> </dd>
- <dt><tt>autokey [</tt><i><tt>logsec</tt></i><tt>]</tt> </dt>
- <dd>Specifies the interval between regenerations of the
- session key list used with the autokey feature. 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> </dd>
- <dt><tt>enable [auth | bclient | kernel | monitor | ntp |
- stats]</tt></dt>
- <dt><tt>disable [auth | bclient | kernel | monitor | ntp |
- stats</tt><font face="Courier New">] </font></dt>
- <dd>Provides a way to enable or disable various server
- options. Flags not mentioned are unaffected. Note that
- all of these flags can be controlled remotely using the <a
- href="ntpdc.htm"><tt>ntpdc</tt></a> utility program.</dd>
- <dd> </dd>
- <dd><dl>
- <dt><tt>auth</tt></dt>
- <dd>Enables the server to synchronize with
- unconfigured peers only if the peer has been
- correctly authenticated using a trusted key and
- key identifier. The default for this flag is
- enable.</dd>
- <dd> </dd>
- <dt><tt>bclient</tt></dt>
- <dd>When enabled, this is identical to the <tt>broadcastclient</tt>
- command. The default for this flag is disable.</dd>
- <dd> </dd>
- <dt><tt>kernel</tt></dt>
- <dd>Enables the precision-time kernel support for the
- <tt>ntp_adjtime()</tt> system call, if
- implemented. Ordinarily, support for this routine
- is detected automatically when the NTP daemon is
- compiled, so it is not necessary for the user to
- worry about this flag. It flag is provided
- primarily so that this support can be disabled
- during kernel development.</dd>
- <dd> </dd>
- <dt><tt>monitor</tt></dt>
- <dd>Enables the monitoring facility. See the <tt>ntpdc</tt>
- program and the <tt>monlist</tt> command or
- further information. The default for this flag is
- enable.</dd>
- <dd> </dd>
- <dt><tt>ntp</tt></dt>
- <dd>Enables the server to adjust its local clock by
- means of NTP. If disabled, the local clock
- free-runs at its intrinsic time and frequency
- offset. This flag is useful in case the local
- clock is controlled by some other device or
- protocol and NTP is used only to provide
- synchronization to other clients. In this case,
- the local clock driver can be used to provide
- this function and also certain time variables for
- error estimates and leap-indicators. See the <a
- href="refclock.htm">Reference Clock Drivers </a>page
- for further information. The default for this
- flag is enable.</dd>
- <dd> </dd>
- <dt><tt>stats</tt></dt>
- <dd>Enables the statistics facility. See the <a
- href="monopt.htm">Monitoring Options </a>page for
- further information. The default for this flag is
- enable.</dd>
- <dd> </dd>
- </dl>
- </dd>
+
+<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>
+
+<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>
+<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>
+
</dl>
-<hr>
+<h4>Bugs</h4>
+
+<p>The syntax checking is not picky; some combinations of ridiculous and
+even hilarious options and modes may not be detected.
-<address>
- David L. Mills (mills@udel.edu)
-</address>
-</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>
- <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
- <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <TITLE>PTB Modem Time Service
-</TITLE>
+ <META NAME="GENERATOR" CONTENT="Adobe PageMill 3.0 per Windows">
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <TITLE>PTB Modem Time Service </TITLE>
</HEAD>
<BODY>
-<H3>
-PTB Modem Time Service</H3>
-
-<HR>
-<H4>
-Synopsis</H4>
-Address: 127.127.23.<I>u</I>
-<BR>Reference ID: <TT>PTB</TT>
-<BR>Driver ID: <TT>ACTS_PTP</TT>
-<BR>Serial Port: <TT>/dev/ptb<I>u</I></TT>; 1200 baud, 8-bits, no parity
-<BR>Requires: <TT>/usr/include/sys/termios.h</TT> header file with modem
-control
-<H4>
-Description</H4>
-No further information available.
-<H4>
-Fudge Factors</H4>
+<H3>PTB Modem Time Service and other European Laboratories Time
+Services</H3>
+
+<HR ALIGN=LEFT>
+
+<H4>Synopsis</H4>
+
+<P>Address: 127.127.23.<I>u</I> <BR>
+Reference ID: <TT>PTB</TT> <BR>
+Driver ID: <TT>ACTS_PTB</TT><BR>
+Serial Port: <TT>/dev/ptb<I>u</I></TT>; 1200 baud, 8-bits, no
+parity <BR>
+Requires: <TT>/usr/include/sys/termios.h</TT> header file with
+modem control</P>
+
+<H4>Description</H4>
+
+<P>This driver supports the PTB Automated Computer Time Service
+(ACTS) and it is a modified version of the NIST ACTS driver so
+see it for more informations..</P>
+
+<P>It periodically dials a prespecified telephone number, receives
+the PTB timecode data and calculates the local clock correction.
+It designed primarily for use when neither a radio clock nor connectivity
+to Internet time servers is available. For the best accuracy,
+the individual telephone line/modem delay needs to be calibrated
+using outside sources.</P>
+
+<P>The only change between this driver and the NIST one is the
+data format. Infact PTB data format is the following:</P>
+
+<P><FONT SIZE="-1" FACE="Courier New">Data format<BR>
+0000000000111111111122222222223333333333444444444455555555556666666666777777777
+ 7<BR>
+0123456789012345678901234567890123456789012345678901234567890123456789012345678
+ 9<BR>
+1995-01-23 20:58:51 MEZ 10402303260219950123195849740+40000500
+ *<BR>
+A B C D EF G H IJ K L M N O P Q R S T U V W
+XY Z<CR><LF><BR>
+A year<BR>
+B month<BR>
+C day<BR>
+D hour<BR>
+E : normally<BR>
+A for DST to ST switch first hour<BR>
+B for DST to ST switch second hour if not marked in H<BR>
+F minute<BR>
+G second<BR>
+H timezone<BR>
+I day of week<BR>
+J week of year<BR>
+K day of year<BR>
+L month for next ST/DST changes<BR>
+M day<BR>
+N hour<BR>
+O UTC year<BR>
+P UTC month<BR>
+Q UTC day<BR>
+R UTC hour<BR>
+S UTC minute<BR>
+T modified julian day (MJD)<BR>
+U DUT1<BR>
+V direction and month if leap second<BR>
+W signal delay (assumed/measured)<BR>
+X sequence number for additional text line in Y<BR>
+Y additional text<BR>
+Z on time marker (* - assumed delay / # measured delay)<BR>
+ <CR>!<LF> ! is second change !<BR>
+</FONT><BR>
+This format is an ITU-R Recommendation (ITU-R TF583.4) and is now available from the primary
+timing centres of the following countries:
+Austria, Belgium, Germany, Italy, The Netherlands, Poland, Portugal, Romania, Spain, Sweden,
+Switzerland, Turkey, United Kingdom.
+Some examples are:
+</P>
+
+<UL>
+ <LI>In Germany by Physikalisch-Technische Bundesanstalt (PTB)'s
+ timecode service. Phone number: +49 5 31 51 20 38.
+</UL>
+
+<BLOCKQUOTE>
+ <P>For more detail, see <A HREF="http://www.ptb.de/english/org/4/43/433/disse.htm">http://www.ptb.de/english/org/4/43/433/disse.htm</A></P>
+</BLOCKQUOTE>
+
+<UL>
+ <LI>In the UK by National Physical Laboratory (NPL)'s TRUETIME
+ service. Phone number: 0891 516 333
+</UL>
+
+<BLOCKQUOTE>
+ <P>For more detail, see <A HREF="http://www.npl.co.uk/npl/ctm/truetime.html">http://www.npl.co.uk/npl/ctm/truetime.html</A></P>
+</BLOCKQUOTE>
+
+<UL>
+ <LI>In Italy by Istituto Elettrotecnico Nazionale "Galileo
+ Ferrais" (IEN)'s CTD service. Phone number: 166 11 46
+ 15
+</UL>
+
+<BLOCKQUOTE>
+ <P>For more detail, see <A HREF="http://www.ien.it/tf/time/Pagina42.html">http://www.ien.it/tf/time/Pagina42.html</A></P>
+</BLOCKQUOTE>
+
+<UL>
+ <LI>In Switzerland by Swiss Federal Office of Metrology 's timecode
+ service. Phone number: 031 323 32 25
+</UL>
+
+<BLOCKQUOTE>
+ <P>For more detail, see <A HREF="http://www.ofmet.admin.ch/de/labors/4/Zeitvert.html%20">http://www.ofmet.admin.ch/de/labors/4/Zeitvert.html
+ </A></P>
+</BLOCKQUOTE>
+
+<UL>
+ <LI>In Sweden by SP Swedish National Testing and Research Institute
+ 's timecode service. Phone number: +46 33 415783
+</UL>
+
+<BLOCKQUOTE>
+ <P>For more detail, see <A HREF="http://www.sp.se/pne/ElectricalMetrology/ElMeteng/frameset.htm">http://www.sp.se/pne/ElectricalMetrology/ElMeteng/frameset.htm</A><BR>
+<BR>
+ </P>
+</BLOCKQUOTE>
+
+<H4>Fudge Factors</H4>
<DL>
-<DT>
-<TT>time1 <I>time</I></TT></DT>
-
-<DD>
-Specifies the time offset calibration factor, in seconds and fraction,
-with default 0.0.</DD>
-
-<DT>
-<TT>time2 <I>time</I></TT></DT>
-
-<DD>
-Not used by this driver.</DD>
-
-<DT>
-<TT>stratum <I>number</I></TT></DT>
-
-<DD>
-Specifies the driver stratum, in decimal from 0 to 15, with default 0.</DD>
-
-<DT>
-<TT>refid <I>string</I></TT></DT>
-
-<DD>
-Specifies the driver reference identifier, an ASCII string from one to
-four characters, with default PTB.</DD>
-
-<DT>
-<TT>flag1 0 | 1</TT></DT>
-
-<DD>
-Not used by this driver.</DD>
+ <DT><TT>time1 <I>time</I></TT>
+ <DD>Specifies the time offset calibration factor, in seconds
+ and fraction, with default 0.0.
+ <DT><TT>time2 <I>time</I></TT>
+ <DD>Not used by this driver.
+ <DT><TT>stratum <I>number</I></TT>
+ <DD>Specifies the driver stratum, in decimal from 0 to 15, with
+ default 0.
+ <DT><TT>refid <I>string</I></TT>
+ <DD>Specifies the driver reference identifier, an ASCII string
+ from one to four characters, with default PTB.
+ <DT><TT>flag1 0 | 1</TT>
+ <DD>Not used by this driver.
+ <DT><TT>flag2 0 | 1</TT>
+ <DD>Not used by this driver.
+ <DT><TT>flag3 0 | 1</TT>
+ <DD>Not used by this driver.
+ <DT><TT>flag4 0 | 1</TT>
+ <DD>Not used by this driver.
+</DL>
-<DT>
-<TT>flag2 0 | 1</TT></DT>
+<P>Additional Information</P>
-<DD>
-Not used by this driver.</DD>
+<P>A keyword in the ntp.conf file permits a direct connection
+to a serial port of source of time like IEN CTD signal. It is
+sufficient to use the string DIRECT in place of the phone number.</P>
-<DT>
-<TT>flag3 0 | 1</TT></DT>
+<P>Example:</P>
-<DD>
-Not used by this driver.</DD>
+<P><FONT FACE="Courier New">server 127.127.23.1</FONT></P>
-<DT>
-<TT>flag4 0 | 1</TT></DT>
+<P><FONT FACE="Courier New">phone DIRECT</FONT></P>
-<DD>
-Not used by this drivert.</DD>
-</DL>
-Additional Information
+<P><A HREF="refclock.htm">Reference Clock Drivers</A> <HR ALIGN=LEFT></P>
-<P><A HREF="refclock.htm">Reference Clock Drivers</A>
-<HR>
-<ADDRESS>
-David L. Mills (mills@udel.edu)</ADDRESS>
+<ADDRESS>by Marco Mascarello (masca@tf.ien.it) for David L. Mills
+(mills@udel.edu)</ADDRESS>
</BODY>
</HTML>
+
--- /dev/null
+<html><head><title>
+<tt>ntp_genkeys</tt> - generate public and private keys
+</title></head><body><h3>
+<tt>ntp_genkeys</tt> - generate public and private keys
+</h3><hr>
+
+<h4>Synopsis</h4>
+
+<tt>ntp_genkeys</tt>
+
+<H4>Description</H4>
+
+<p>The cryptographic values used by the <tt>autokey</tt> scheme are
+incorporated as a set of four files generated by the
+<tt>ntp_genkeys</tt> program, including <tt>ntp.keys</tt> containing the
+DES/MD5 private keys, <tt>ntpkey</tt> containing the RSA private key,
+<tt>ntpkey_<i>host</i></tt> containing the RSA public key, where
+<tt><i>host</i></tt> is the DNS name of the generating machine, and
+<tt>ntpkey_dh</tt> containing the parameters for the Diffie-Hellman key-
+agreement algorithm. The files contain cryptographic values generated by
+the algorithms of the <tt>rsaref20</tt> package and are in printable
+ASCII format. Since the algorythms are seeded by the system clock, each
+run of this program will produce a different outcome. There are no
+options or frills of any sort, although a number of options would seem
+to be appropriate.
+
+<p>The <tt>ntp.keys</tt> file contains 16 MD5 keys. Each key consists of
+16 characters randomized over the ASCII 95-character printing subset.
+The file is read by the daemon at the location specified by the
+<tt>keys</tt> configuration file command and made visible only to root.
+An additional key consisting of a easily remembered password should be
+added by hand for use with the <tt>ntpq</tt> and <tt>ntpdc</tt>
+programs. The file must be distributed by secure means to other servers
+and clients sharing the same security compartment. While the key
+identifiers for MD5 and DES keys must be in the range 1-65534,
+inclusive, the <tt>ntp_genkeys</tt> program uses only the identifiers
+from 1 to 16. The key identifier for each association is specified as
+the key argument in the <tt>server</tt> or peer configuration file
+command.
+
+<p>The <tt>ntpkey</tt> file contains the RSA private key. It is read by
+the daemon at the location specified by the <tt>privatekey</tt> argument
+of the <tt>crypto</tt> configuration file command and made visible only
+to root. This file is useful only to the machine that generated it and
+never shared with any other daemon or application program.
+
+<p>The <tt>ntpkey_<i>host</i></tt> file contains the RSA public key,
+where <tt><i>host</i></tt> is the DNS name of the host that generated
+it. The file is read by the daemon at the location specified by the
+<tt>publickey</tt> argument to the <tt>server</tt> or <tt>peer</tt>
+configuration file command. This file can be widely distributed and
+stored without using secure means, since the data are public values.
+
+<p>The <tt>ntp_dh</tt> file contains two Diffie-Hellman parameters: the
+prime modulus and the generator. The file is read by the daemon at the
+location specified by the <tt>dhparams</tt> argument of the
+<tt>crypto</tt> configuration file command. The file can be distributed
+by insecure means to other servers and clients sharing the same key
+agreement compartment, since the data are public values.
+
+<p>The file formats all begin with two lines, the first containing the
+generating system DNS name and the second the datestamp. Lines beginning
+with <tt>#</tt> are considered comments and ignored by the daemon. In
+the <tt>ntp.keys</tt> file, the next 16 lines contain the MD5 keys in
+order. In the <tt>ntpkey</tt> and <tt>ntpkey_<i>host</i></tt> files, the
+next line contains the modulus length in bits followed by the key as a
+PEM encoded string. In the <tt>ntpkey_dh</tt> file, the next line
+contains the prime length in bytes followed by the prime as a PEM
+encoded string, and the next and final line contains the generator
+length in bytes followed by the generator as a PEM encoded string.
+
+<p>Note: See the file <tt>./source/rsaref.h</tt> in the
+<tt>rsaref20</tt> package for explanation of return values, if
+necessary.
+
+<h4>Files</h4>
+
+The RSA Laboratories package <tt>rsaref20</tt> of cryptographic routines
+is necessary in order to build and use this program.
+
+<h4>Bugs</h4>
+
+It can take quite a while to generate the RSA public/private key pair
+and Diffie-Hellman parameters, from a few seconds on a modern
+workstation to several minutes on older machines.
+
+<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>
ToDo</h2>
<ul>
+<li>
+MD5 authentication causes problems with DNS. If you use encryption/authentication,
+you have to use IP numbers in <tt>ntp.conf.</tt></li>
+
<li>
NMEA refclock support is in development.</li>
Bug Reports</h2>
Send bug reports to <a href="news://comp.protocols.time.ntp">news://comp.protocols.time.ntp</a>
and Sven_Dietrich@Trimble.COM
-<br>
<h2>
Change Log</h2>
-<h3>
-Last revision 21 February 1999 Version 4.0.99f.</h3>
-<b>from Carl Byington <carl@five-ten-sg.com></b>
-<p><b>Significant Changes:</b>
-<br>
-<li>
-MD5 authentication caused problems with DNS. If you use encryption/authentication,
-you had to use IP numbers in <tt>ntp.conf.</tt></li>
-
-<li>
-Carl's patch fixes these problems and MD5 seems to be fully functional.</li>
-
<h3>
Last revision 16 February 1999 Version 4.0.99e.</h3>
<b>by Sven Dietrich (sven_dietrich@trimble.com)</b>
variables</A></LI>
<LI><A HREF=ntptime.htm><TT>ntptime</TT> - read kernel time
variables</A></LI>
+<LI><A HREF=genkeys.htm><TT>ntp_genkeys</TT> - generate public and
+private keys</A></LI>
</ul>
<LI><A HREF=kern.htm>A Kernel Model for Precision Timekeeping</A></LI>
<LI><A HREF=kernpps.htm>A Kernel Programming Interface for Precision
Time Signals</A></LI>
-
</ul>
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
- <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <TITLE>Miscellaneous Options
-</TITLE>
-</HEAD>
-<BODY>
-
-<H3>
-Miscellaneous Options</H3>
-
-<HR>
-<DL>
-<DT>
-<TT>broadcastdelay <I>seconds</I></TT></DT>
-
-<DD>
-The broadcast and multicast modes require a special calibration to determine
-the network delay between the local and remote servers. Ordinarily, this
-is done automatically by the initial protocol exchanges between the local
-and remote servers. In some cases, the calibration procedure may fail due
-to network or server access controls, for example. This command specifies
-the default delay to be used under these circumstances. Typically (for
-Ethernet), a number between 0.003 and 0.007 seconds is appropriate. The
-default when this command is not used is 0.004 seconds.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>trap <I>host_address</I> [port <I>port_number</I>] [interface <I>interface_address</I>]</TT></DT>
-
-<DD>
-This command configures a trap receiver at the given host address and port
-number for sending messages with the specified local interface address.
-If the port number is unspecified. a value of 18447 is used. If the interface
-address is not specified, the message is sent with a source address of
-the local interface the message is sent through. Note that on a multihomed
-host the interface used may vary from time to time with routing changes.</DD>
-
-<DD>
-The trap receiver will generally log event messages and other information
-from the server in a log file. While such monitor programs may also request
-their own trap dynamically, configuring a trap receiver will ensure that
-no messages are lost when the server is started.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>setvar <I>variable</I> [default]</TT></DT>
-
-<DD>
-This command adds an additional system variable. These variables can be
-used to distribute additional information such as the access policy. If
-the variable of the form <TT><I>name</I> = <I>value</I></TT> is followed
-by the <TT>default</TT> keyword, the variable will be listed as part of
-the default system variables (<TT>ntpq rv</TT> command). These additional
-variables serve informational purposes only. They are not related to the
-protocol other that they can be listed. The known protocol variables will
-always override any variables defined via the <TT>setvar</TT> mechanism.
-There are three special variables that contain the names of all variable
-of the same group. The <TT>sys_var_list</TT> holds the names of all system
-variables. The <TT>peer_var_list</TT> holds the names of all peer variables
-and the <TT>clock_var_list</TT> holds the names of the reference clock
-variables.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>logfile <I>logfile</I></TT></DT>
-
-<DD>
-This command specifies the location of an alternate log file to be used
-instead of the default system <TT>syslog</TT> facility.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>logconfig <I>configkeyword</I></TT></DT>
-
-<DD>
-This command controls the amount and type of output written to the system
-<TT>syslog</TT> facility or the alternate <TT>logfile</TT> log file. By
-default, all output is turned on. All <I><TT>configkeyword</TT></I> keywords
-can be prefixed with <TT>=</TT>, <TT>+</TT> and <TT>-</TT>, where <TT>=</TT>
-sets the <TT>syslogmask</TT>, <TT>+</TT> adds and <TT>-</TT> removes messages.
-<TT>syslog messages</TT> can be controlled in four classes (, <TT>peer</TT>,
-<TT>sys</TT> and <TT>sync</TT>). Within these classes four types of messages
-can be controlled.</DD>
-
-<DD>
-Informational messages (<TT>info</TT>) control configuration information.
-Event messages (<TT>events</TT>) control logging of events (reachability,
-synchronization, alarm conditions). Statistical output is controlled with
-the <TT>statistics</TT> keyword. The final message group is the status
-messages. This describes mainly the synchronizations status. Configuration
-keywords are formed by concatenating the message class with the event class.
-The <TT>allprefix</TT> can be used instead of a message class. A message
-class may also be followed by the <TT>all</TT> keyword to enable/disable
-all messages of the respective message class.</DD>
-
-<DD>
-Thus, a minimal log configuration could look like this:</DD>
-
-<DD>
-<TT>logconfig = syncstatus +sysevents</TT></DD>
-
-<DD>
-This would just list the synchronizations state of <TT>ntpd</TT> and the
-major system events. For a simple reference server, the following minimum
-message configuration could be useful:</DD>
-
-<DD>
-<TT>logconfig = syncall +clockall</TT></DD>
-
-<DD>
-This configuration will list all clock information and synchronization
-information. All other events and messages about peers, system events and
-so on is suppressed.</DD>
-</DL>
-
-<H4>
-Variables</H4>
-Most variables used by the NTP protocol can be examined with the <TT>ntpdc</TT>
-(mode 7 messages) and the <TT>ntpq</TT> (mode 6 messages). Currently, very
-few variables can be modified via mode 6 messages. These variables are
-either created with the <TT>setvar</TT> directive or the leap warning bits.
-The leap warning bits can be set in the <TT>leapwarning</TT> variable up
-to one month ahead. Both the <TT>leapwarning</TT> and <TT>leapindication</TT>
-variables have a slightly different encoding than the usual leap bits interpretation:
-<DL>
-<DT>
-<TT>00</TT></DT>
-
-<DD>
-The daemon passes the leap bits of its synchronization source (usual mode
-of operation).</DD>
-
-<DT>
-<TT>01/10</TT></DT>
-
-<DD>
-A leap second is added/deleted (operator forced leap second).</DD>
-
-<DT>
-<TT>11</TT></DT>
-
-<DD>
-Leap information from the synchronizations source is ignored (thus <TT>LEAP_NOWARNING</TT>
-is passed on).</DD>
-</DL>
-
-<HR>
-<ADDRESS>
-David L. Mills (mills@udel.edu)</ADDRESS>
-
-</BODY>
-</HTML>
+<html><head><title>
+Miscellaneous Options
+</title></head><body><h3>
+Miscellaneous Options
+</h3><hr>
+
+<dl>
+
+<dt><tt>broadcastdelay <I>seconds</I></tt></dt>
+<dd>The broadcast and multicast modes require a special calibration to
+determine the network delay between the local and remote servers.
+Ordinarily, this is done automatically by the initial protocol exchanges
+between the client and server. In some cases, the calibration
+procedure may fail due to network or server access controls, for
+example. This command specifies the default delay to be used under these
+circumstances. Typically (for Ethernet), a number between 0.003 and
+0.007 seconds is appropriate. The default when this command is not used
+is 0.004 seconds.</dd>
+
+<dt><tt>driftfile <i>driftfile</i></tt>
+<dd>This command specifies the name of the file used to record the
+frequency offset of the local clock oscillator. If the file exists, it
+is read at startup in order to set the initial frequency offset and then
+updated once per hour with the current frequency offset computed by the
+daemon. If the file does not exist or this command is not given, the
+initial frequency offset is assumed zero. In this case, it may take some
+hours for the frequency to stabilize and the residual timing errors to
+subside.</dd>
+
+<p><dd>The file format consists of a single line containing a single
+floating point number, which records the frequency offset measured in
+parts-per-million (PPM). The file is updated by first writing the
+current drift value into a temporary file and then renaming this file to
+replace the old version. This implies that <tt>ntpd</tt> must have write
+permission for the directory the drift file is located in, and that file
+system links, symbolic or otherwise, should be avoided.</dd>
+
+<dt><tt>enable [auth | bclient | kernel | monitor | ntp | stats]</tt>
+<br><tt>disable [auth | bclient | kernel | monitor | ntp | stats</tt>
+<dd>Provides a way to enable or disable various server options. Flags
+not mentioned are unaffected. Note that all of these flags can be
+controlled remotely using the <a href="ntpdc.htm"><tt>ntpdc</tt></a>
+utility program.</dd>
+
+<dd><dl>
+
+<dt><tt>auth</tt></dt>
+<dd>Enables the server to synchronize with unconfigured peers only if
+the peer has been correctly authenticated using a trusted key and key
+identifier. The default for this flag is <tt>enable</tt>.</dd>
+
+<dt><tt>bclient</tt></dt>
+<dd>When enabled, this is identical to the <tt>broadcastclient</tt>
+command. The default for this flag is <tt>disable</tt>.</dd>
+
+<dt><tt>kernel</tt></dt>
+<dd>Enables the precision-time kernel support for the
+<tt>ntp_adjtime()</tt> system call, if implemented. Ordinarily, support
+for this routine is detected automatically when the NTP daemon is
+compiled, so it is not necessary for the user to worry about this flag.
+It flag is provided primarily so that this support can be disabled
+during kernel development. The default for this flag is
+<tt>enable</tt>.</dd>
+
+<dt><tt>monitor</tt></dt>
+<dd>Enables the monitoring facility. See the <tt>ntpdc</tt> program and
+the <tt>monlist</tt> command or further information. The default for
+this flag is <tt>enable</tt>.</dd>
+
+<dt><tt>ntp</tt></dt>
+<dd>Enables the server to adjust its local clock by means of NTP. If
+disabled, the local clock free-runs at its intrinsic time and frequency
+offset. This flag is useful in case the local clock is controlled by
+some other device or protocol and NTP is used only to provide
+synchronization to other clients. In this case, the local clock driver
+can be used to provide this function and also certain time variables for
+error estimates and leap-indicators. See the <a
+href="refclock.htm">Reference Clock Drivers </a>page for further
+information. The default for this flag is <tt>enable</tt>.</dd>
+
+<dt><tt>stats</tt></dt>
+<dd>Enables the statistics facility. See the <a
+href="monopt.htm">Monitoring Options </a>page for further information.
+The default for this flag is <tt>enable</tt>.</dd>
+
+</dl>
+
+<dt><tt>logconfig <I>configkeyword</I></tt></dt>
+<dd>This command controls the amount and type of output written to the
+system <tt>syslog</tt> facility or the alternate <tt>logfile</tt> log
+file. By default, all output is turned on. All
+<I><tt>configkeyword</tt></I> keywords can be prefixed with <tt>=</tt>,
+<tt>+</tt> and <tt>-</tt>, where <tt>=</tt> sets the
+<tt>syslogmask</tt>, <tt>+</tt> adds and <tt>-</tt> removes messages.
+<tt>syslog messages</tt> can be controlled in four classes (,
+<tt>peer</tt>, <tt>sys</tt> and <tt>sync</tt>). Within these classes
+four types of messages can be controlled.</dd>
+
+<dd>Informational messages (<tt>info</tt>) control configuration
+information. Event messages (<tt>events</tt>) control logging of events
+(reachability, synchronization, alarm conditions). Statistical output is
+controlled with the <tt>statistics</tt> keyword. The final message group
+is the status messages. This describes mainly the synchronizations
+status. Configuration keywords are formed by concatenating the message
+class with the event class. The <tt>allprefix</tt> can be used instead
+of a message class. A message class may also be followed by the
+<tt>all</tt> keyword to enable/disable all messages of the respective
+message class.</dd>
+
+<dd>Thus, a minimal log configuration could look like this:</dd>
+
+<p><dd><tt>logconfig = syncstatus +sysevents</tt></dd>
+
+<p><dd>This would just list the synchronizations state of <tt>ntpd</tt>
+and the major system events. For a simple reference server, the
+following minimum message configuration could be useful:</dd>
+
+<p><dd><tt>logconfig = syncall +clockall</tt></dd>
+
+<p><dd>This configuration will list all clock information and
+synchronization information. All other events and messages about peers,
+system events and so on is suppressed.</dd>
+
+<dt><tt>logfile <I>logfile</I></tt></dt>
+<dd>This command specifies the location of an alternate log file to be
+used instead of the default system <tt>syslog</tt> facility.</dd>
+
+<dt><tt>setvar <I>variable</I> [default]</tt></dt>
+<dd>This command adds an additional system variable. These variables can
+be used to distribute additional information such as the access policy.
+If the variable of the form <tt><I>name</I> = <I>value</I></tt> is
+followed by the <tt>default</tt> keyword, the variable will be listed as
+part of the default system variables (<tt>ntpq rv</tt> command). These
+additional variables serve informational purposes only. They are not
+related to the protocol other that they can be listed. The known
+protocol variables will always override any variables defined via the
+<tt>setvar</tt> mechanism. There are three special variables that
+contain the names of all variable of the same group. The
+<tt>sys_var_list</tt> holds the names of all system variables. The
+<tt>peer_var_list</tt> holds the names of all peer variables and the
+<tt>clock_var_list</tt> holds the names of the reference clock
+variables.</dd>
+
+<dt><tt>trap <I>host_address</I> [port <I>port_number</I>] [interface
+<I>interface_address</I>]</tt></dt>
+<dd>This command configures a trap receiver at the given host address
+and port number for sending messages with the specified local interface
+address. If the port number is unspecified. a value of 18447 is used. If
+the interface address is not specified, the message is sent with a
+source address of the local interface the message is sent through. Note
+that on a multihomed host the interface used may vary from time to time
+with routing changes.</dd>
+
+<dd>The trap receiver will generally log event messages and other
+information from the server in a log file. While such monitor programs
+may also request their own trap dynamically, configuring a trap receiver
+will ensure that no messages are lost when the server is started.</dd>
+
+</dl>
+
+<h4>Files</h4>
+
+<tt>ntp.drift</tt> frequency compensation (PPM)
+
+<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>
- <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
- <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <TITLE>tickadj - set time-related kernel variables
-</TITLE>
-</HEAD>
-<BODY>
-
-<H3>
-<TT>tickadj</TT> - set time-related kernel variables</H3>
-
-<HR>
-<H4>
-Synopsis</H4>
+<HTML><HEAD><TITLE>
+<TT>tickadj</TT> - set time-related kernel variables
+</TITLE></HEAD><BODY><H3>
+<TT>tickadj</TT> - set time-related kernel variables
+</H3><HR>
+
+<H4>Synopsis</H4>
+
<TT>tickadj [ -Aqs ] [ -a <I>tickadj</I> ] [ -t <I>tick</I> ]</TT>
-<H4>
-Description</H4>
-The <TT>tickadj</TT> program reads, and optionally modifies, several timekeeping-related
-variables in the running kernel, via <TT>/dev/kmem</TT>. The particular
-variables it is concerned with are <TT>tick</TT>, which is the number of
-microseconds added to the system time during a clock interrupt, <TT>tickadj</TT>,
-which sets the slew rate and resolution used by the <TT>adjtime</TT> system
-call, and <TT>dosynctodr</TT>, which indicates to the kernels on some machines
-whether they should internally adjust the system clock to keep it in line
-with time-of-day clock or not.
-
-<P>We have a report that says starting with Solaris 2.6 we should
-leave <I>dosynctodr</I> alone.
-<A HREF="solaris-dosynctodr.html">Here is the report</A>.
+
+<H4>Description</H4>
+
+The <TT>tickadj</TT> program reads, and optionally modifies, several
+timekeeping-related variables in the running kernel in some machines,
+via <TT>/dev/kmem</TT>. The particular variables it is concerned with
+are <TT>tick</TT>, which is the number of microseconds added to the
+system time during a clock interrupt, <TT>tickadj</TT>, which sets the
+slew rate and resolution used by the <TT>adjtime</TT> system call, and
+<TT>dosynctodr</TT>, which indicates to the kernels on some machines
+whether they should internally adjust the system clock to keep it in
+line with time-of-day clock or not.
+
+<P>Note that this program does NOT work in some kernels, in particular
+Solaris 2.6 or later. See the <A HREF="solaris-dosynctodr.html">
+report</A>.
<P>By default, with no arguments, <TT>tickadj</TT> reads the variables
-of interest in the kernel and displays them. At the same time, it determines
-an "optimal" value for the value of the <TT>tickadj</TT> variable if the
-intent is to run the <TT>ntpd</TT> Network Time Protocol (NTP) daemon,
-and prints this as well. Since the operation of <TT>tickadj</TT> when reading
-the kernel mimics the operation of similar parts of the <TT>ntpd</TT> program
-fairly closely, this can be useful when debugging problems with <TT>ntpd</TT>.
+of interest in the kernel and displays them. At the same time, it
+determines an "optimal" value for the value of the <TT>tickadj</TT>
+variable if the intent is to run the <TT>ntpd</TT> Network Time Protocol
+(NTP) daemon, and prints this as well. Since the operation of
+<TT>tickadj</TT> when reading the kernel mimics the operation of similar
+parts of the <TT>ntpd</TT> program fairly closely, this can be useful
+when debugging problems with <TT>ntpd</TT>.
<P>Note that <TT>tickadj</TT> should be run with some caution when being
used for the first time on different types of machines. The operations
-which <TT>tickadj</TT> tries to perform are not guaranteed to work on all
+which <TT>tickadj</TT> tries to perform are not guaranteed to work on
+all
Unix machines and may in rare cases cause the kernel to crash.
<H4>
Command Line Options</H4>
<DL>
-<DT>
-<TT>-a <I>tickadj</I></TT></DT>
-<DD>
-Set the kernel variable <TT>tickadj</TT> to the value <I><TT>tickadj</TT></I>
-specified.</DD>
+<DT><TT>-a <I>tickadj</I></TT></DT>
+<DD>Set the kernel variable <TT>tickadj</TT> to the value
+<I><TT>tickadj</TT></I>specified.</DD>
-<DT>
-<TT>-A</TT></DT>
+<DT><TT>-A</TT></DT>
+<DD>Set the kernel variable <TT>tickadj</TT> to an internally computed
+"optimal" value.</DD>
-<DD>
-Set the kernel variable <TT>tickadj</TT> to an internally computed "optimal"
-value.</DD>
+<DT><TT>-t <I>tick</I></TT></DT>
+<DD>Set the kernel variable <TT>tick</TT> to the value
+<I><TT>tick</TT></I> specified.</DD>
-<DT>
-<TT>-t <I>tick</I></TT></DT>
+<DT><TT>-s</TT></DT>
+<DD>Set the kernel variable <TT>dosynctodr</TT> to zero, which disables
+the hardware time-of-year clock, a prerequisite for running the
+<TT>ntpd</TT> daemon under SunOS4.</DD>
-<DD>
-Set the kernel variable <TT>tick</TT> to the value <I><TT>tick</TT></I>
-specified.</DD>
+<DT><TT>-q</TT></DT>
+<DD>Normally, <TT>tickadj</TT> is quite verbose about what it is doing.
+The <TT>-q</TT> flag tells it to shut up about everything except
+errors.</DD>
-<DT>
-<TT>-s</TT></DT>
-
-<DD>
-Set the kernel variable <TT>dosynctodr</TT> to zero, which disables the
-hardware time-of-year clock, a prerequisite for running the <TT>ntpd</TT>
-daemon under SunOS4.</DD>
-
-<DT>
-<TT>-q</TT></DT>
-
-<DD>
-Normally, <TT>tickadj</TT> is quite verbose about what it is doing. The
-<TT>-q</TT> flag tells it to shut up about everything except errors.</DD>
</DL>
-<H4>
-Files</H4>
+<H4>Files</H4>
<PRE>
/vmunix
/dev/kmem</PRE>
-<H4>
-Bugs</H4>
-Fiddling with kernel variables at run time as a part of ordinary operations
-is a hideous practice which is only necessary to make up for deficiencies
-in the implementation of <TT>adjtime</TT> in many kernels and/or brokenness
-of the system clock in some vendors' kernels. It would be much better if
-the kernels were fixed and the <TT>tickadj</TT> program went away.
-<HR>
-<ADDRESS>
-David L. Mills (mills@udel.edu)</ADDRESS>
-
-</BODY>
-</HTML>
+<H4>Bugs</H4>
+
+Fiddling with kernel variables at run time as a part of ordinary
+operations is a hideous practice which is only necessary to make up for
+deficiencies in the implementation of <TT>adjtime</TT> in many kernels
+and/or brokenness of the system clock in some vendors' kernels. It would
+be much better if the kernels were fixed and the <TT>tickadj</TT>
+program went away.
+
+<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>
projects / thirdparty / ntp.git / commitdiff
