From: Harlan Stenn Date: Fri, 17 Aug 2007 05:38:48 +0000 (-0400) Subject: Cleanup from Dave Mills X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4a4ddcc4e38a2238e484d1fe4e72b084793f1fd5;p=thirdparty%2Fntp.git Cleanup from Dave Mills bk: 46c53468JJvvNkeM52YFLpjVShN6Jw --- diff --git a/html/assoc.html b/html/assoc.html index 0ca1426501..41a8a5c229 100644 --- a/html/assoc.html +++ b/html/assoc.html @@ -13,7 +13,7 @@

Association Management

giffrom Alice's Adventures in Wonderland, Lewis Carroll

Make sure who your friends are.

-

Last update: 18:35 UTC Thursday, July 28, 2005

+

Last update: 02:59 UTC Tuesday, August 14, 2007


Related Links

@@ -24,34 +24,43 @@
  • Symmetric Active/Passive Mode
  • Broadcast/Multicast Modes
  • Multicasting -
  • Multicasting +
  • Orphan Mode
  • Burst Modes

    Association Modes

    -

    NTP Version 4 (NTPv4) incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms; however, it continues the tradition of backwards compatibility with older versions. A number of new operating modes for automatic server discovery and improved accuracy in occasionally connected networks are provided. Following is an overview of the new features; additional information is available on the Configuration Options and Authentication Options pages and in the papers, reports, memoranda and briefings at www.ntp.org.

    -

    There are two types of associations: persistent associations, which result from configuration file commands, and ephemeral associations, which result from protocol operations described below. A persistent association is never demobilized, although it may become dormant when the associated server becomes unreachable. An ephemeral association is mobilized when a message arrives from a server; for instance, a symmetric passive association is mobilized upon arrival of a symmetric active message. A broadcast client association is mobilized upon arrival of a broadcast server message, while a Manycast client association is mobilized upon arrival of a Manycast server message.

    -

    Ordinarily, successful mobilization of an ephemeral association requires the server to be cryptographically authenticated to the dependent client. This can be done using either symmetric-key or public-key cryptography, as described in the Authentication Options page. The cryptographic means insure an unbroken chain of trust between the dependent client and the primary servers at the root of the synchronization subnet. We call this chain the provenance of the client and define new vocabulary as to proventicate a client or provide proventic credentials. Once mobilized, ephemeral associations are demobilized when either (a) the server becomes unreachable or (b) the server refreshes the key media without notifying the client.

    -

    There are three principal modes of operation: client/server, symmetric active/passive and broadcast. In addition, there are two modes using IP multicast support: multicast and manycast. These modes are selected based on the scope of service, intended flow of time and proventic values and means of configuration. Following is a summary of the operations in each mode.

    +

    NTP Version 4 (NTPv4) incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms; however, it continues the tradition of backwards compatibility with older versions. A number of new operating modes for automatic server discovery and improved accuracy in occasionally connected networks are provided. Following is an overview of the various modes of operation; additional information is available on the Configuration Options and Authentication Options pages and in the papers, reports, memoranda and briefings at www.ntp.org.

    +

    There are three types of associations: persistent associations, which result from configuration file commands, and preemptable and ephemeral associations, which result from protocol operations described below. A persistent association is never demobilized, although it may become dormant when the associated server becomes unavailable. Preemptable and ephemeral associations are mobilized when a message arrives from a server; for instance, a symmetric passive association is mobilized upon arrival of a symmetric active message. A broadcast client association is mobilized upon arrival of a broadcast server message, while a manycast client association is mobilized upon arrival of a manycast server message. Preemptable associations differ from ephemeral associations in that the former can be demobilized by the mitigation algorithms when a "better" server comes along, while the latter can be demobilized only by protocol error or timeout.

    +

    Ordinarily, successful mobilization of preemptable or ephemeral associations requires the server to be cryptographically authenticated to the dependent client. This can be done using either symmetric key or public key cryptography, as described in the Authentication Options page.

    +

    There are three principal modes of operation: client/server, symmetric active/passive and broadcast. In addition, there are two modes using IP multicast support: multicast and manycast. These modes are selected based on the scope of service, intended flow of time and cryptographic values and means of configuration.

    +

    The original NTPv3 authentication scheme is applicable in all mode, ass well as the new NTPv4 Autokey authentication scheme. In addition, the orphan and burst modes described below can be used in appropriate cases. Following is a summary of the operations in each mode.

    Client/Server Mode

    -

    Client/server mode is probably the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers. In this mode a client sends a request to the server and expects a reply at some future time. In some contexts this would be described as a "pull" operation, in that the client pulls the time and proventic values from the server. A client is configured in client mode using the server (sic) command and specifying the server IPv4 or IPv6 DNS name or address; the server requires no prior configuration. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme. In addition, two burst modes described below can be used in appropriate cases.

    +

    Client/server mode is probably the most common configuration in the Internet today. It operates in the classic remote-procedure-call (RPC) paradigm with stateless servers. In this mode a client sends a request to the server and expects a reply at some future time. In some contexts this would be described as a "pull" operation, in that the client pulls the time and cryptographic values from the server. A client is configured in client mode using the server (sic) command and specifying the server IPv4 or IPv6 DNS name or address; the server requires no prior configuration.

    +

    The IBURST mode described later on this page is recommended for use by clients, as this speeds up initial synchronization from several minutes to several seconds. The BURST mode described later on this page us useful to improve jitter on very noisy dial-up or ISDN network links. This mode should always be used when the maximum expected poll interval is above 1024 s.

    Symmetric Active/Passive Mode

    -

    Symmetric active/passive mode is intended for configurations were a clique of low-stratum peers operate as mutual backups for each other. Each peer operates with one or more primary reference sources, such as a radio clock, or a subset of secondary servers known to be reliable and proventicated. Should one of the peers lose all reference sources or simply cease operation, the other peers will automatically reconfigure so that time and proventication values can flow from the surviving peers to all the others in the clique. In some contexts this would be described as a "push-pull" operation, in that the peer either pulls or pushes the time and proventic values depending on the particular configuration.

    -

    Symmetric peers operate with their sources in some NTP mode and with each other in symmetric mode. A peer is configured in symmetric active mode using the peer command and specifying the other peer IPv4 or IPv6 DNS name or address. The other peer can also be configured in symmetric active mode in a similar way. However, if the other peer is not specifically configured in this way, a symmetric passive association is mobilized upon arrival of a symmetric active message. Since an intruder can impersonate a symmetric active peer and inject false time values, symmetric mode should always be cryptographically validated. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme.

    +

    Symmetric active/passive mode is intended for configurations were a clique of low-stratum peers operate as mutual backups for each other. Each peer operates with one or more primary reference sources, such as a radio clock, or a subset of secondary servers known to be reliable and authenticated. Should one of the peers lose all reference sources or simply cease operation, the other peers will automatically reconfigure so that time and proventication values can flow from the surviving peers to all the others in the clique. In some contexts this would be described as a "push-pull" operation, in that the peer either pulls or pushes the time and proventic values depending on the particular configuration.

    +

    Symmetric peers operate with their sources in some NTP mode and with each other in symmetric mode. A peer is configured in symmetric active mode using the peer command and specifying the other peer IPv4 or IPv6 DNS name or address. The other peer can also be configured in symmetric active mode in a similar way. However, if the other peer is not specifically configured in this way, a symmetric passive association is mobilized upon arrival of a symmetric active message. Since an intruder can impersonate a symmetric active peer and inject false time values, symmetric mode should always be cryptographically validated.

    +

    The BURST and IBURST modes should not be used in symetric- modes, as this can upset the intended symmetry of the protocol and result in spurious duplicate or dropped messages. In those topologies where symmetric modes are indicates, it is generally best to set the maximum poll interval to the valu of the minimum poll interval.

    Broadcast/Multicast Modes

    IPv4 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. In IPv6 and 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.

    -

    IPv4 broadcast mode is intended for configurations involving one or a few servers and a possibly very large client population on the same subnet. A broadcast server is configured using the broadcast command and a IPv4 local subnet broadcast address. A broadcast client is configured using the broadcastclient command, in which case it responds to broadcast messages received on any interface. Since an intruder can impersonate a broadcast server and inject false time values, this mode should always be cryptographically validated. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv4 Autokey proventication scheme.

    -

    The server generates broadcast messages continuously at intervals specified by the minpoll keyword and with a time-to-live span specified by the ttl keyword. A broadcast client responds to the first message received by waiting a short interval to avoid implosion at the server. Then, the client polls the server in burst mode in order to quickly set the host clock and validate the source. This normally results in a volley of eight client/server cycles at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently. Following the volley, the client computes the offset between the apparent broadcast time and the (unicast) client time. This offset is used to compensate for the propagation time between the broadcast server and client. Once the offset is computed, the server continues as before and the client sends no further messages. If for some reason the broadcast server does not respond to client messages, the client will time out the volley and continue in listen-only mode with a default propagation delay.

    +

    IPv4 broadcast mode is intended for configurations involving one or a few servers and a possibly very large client population on the same subnet. A broadcast server is configured using the broadcast command and a IPv4 local subnet broadcast address. A broadcast client is configured using the broadcastclient command, in which case it responds to broadcast messages received on any interface. Since an intruder can impersonate a broadcast server and inject false time values, this mode should always be cryptographically validated.

    +

    The server generates broadcast messages continuously at intervals specified by the minpoll keyword and with a time-to-live span specified by the ttl keyword. A broadcast client responds to the first message received by waiting a short interval to avoid implosion at the server. Then, the client polls the server in IBURST mode in order to quickly set the host clock and validate the source. This normally results in a volley of eight client/server cycles at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently. Following the volley, the client computes the offset between the apparent broadcast time and the (unicast) client time. This offset is used to compensate for the propagation time between the broadcast server and client. Once the offset is computed, the server continues as before and the client sends no further messages. If for some reason the broadcast server does not respond to client messages, the client will time out the volley and continue in listen-only mode with a default propagation delay.

    Multicasting

    Multicasting can be used to extend the scope of a timekeeping 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 IPv4 or IPv6 multicast group 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 IPv4 224.0.1.1 and IPv6 FF05::101 (site local) to NTP, but these addresses should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped IPv4 group addresses should be used, as described in RFC-2365, or GLOP group addresses, as described in RFC-2770.

    A multicast server is configured using the broadcast command, but with a multicast group address instead of a broadcast address. A multicast client is configured using the multicastclient command with a multicast group address. However, there is a subtle difference between IPv4 broadcasting and multicasting. IPv4 broadcasting is specific to each interface and local subnet address. If more than one interface is attached to a machine, a separate broadcast command applies to each one separately. This provides a way to limit exposure in a firewall, for example. For IPv6 the same distinction can be made using link-local prefix FF02 for each interface and site-local FF05 for all interfacesl.

    IP multicasting is a different paradigm. By design, multicast messages travel from the sender via a shortest-path or shared tree to the receivers, which may require these messages emit from one or all interfaces, but carry a common source address. However, it is possible to configure multiple multicast group addresses using multiple broadcast or multicastclient commands. Other than these particulars, multicast messages are processed just like broadcast messages. Note that the calibration feature in broadcast mode is extremely important, since IP multicast messages can travel far different paths through the IP routing fabric than ordinary IP unicast messages.

    Manycasting

    Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a multicast client to troll the nearby network neighborhood to find cooperating manycast servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each manycast client mobilizes client associations with some number of the "best" of the nearby anycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the Automatic NTP Configuration Options page.

    +

    Orphan Mode

    + Orphan mode is designed for use in private networks with no connectivity to public time servers and without access to a radio clock or modem time service. It is also useful as backup when such support is available but for one reason or another it fails or becomes seriously degraded. Under conditions when all synchronization sources are lost, the network automatically reorganizes so that all synchronization is ultimately dependent on a single orphan host which need not be explicitly selected in advance. In this design the network time might not be synchronized to UTC, but all network hosts will follow the orphan host time. +

    Orphan mode is similar to the local clock driver; but, unlike the local clock driver, there can be more than one orphan host that potentially can assume that role with selection determined by an election algorithm command. Typically, one or more hosts near or at the root of the synchronization tree are assigned an orphan stratum using the tos orphan command. During initialization orphan hosts are assigned a random metric conveyed between hosts at orphan stratum level in the root delay field of the NTP packet header.

    +

    If the orphan hosts have access to servers at lower stratum levels, they operate in the usual way and with strict adherence to the NTP protocol rules. If not and they communicate with each other, the host with the lowest root delay becomes the root server and the remaining hosts in the network use the NTP protocol to determine the network topology. When the original connectivity is restored, the topology is restored.

    +

    Two scenarios will clarify how orphan mode can be used to provide smart backup. The first, scenario includes two secondary servers normally synchronized to different public Internet primary servers and connected to the same Ethernet LAN. Each are configured with broadcast and broadcastclient commands and in addition the tos orphan command. If one of the primary servers becomes unavailable, the associated LAN server will resynchronize to the other LAN server as a consequence of normal NTP operations. If both primary servers become unavailable, both LAN servers will eventually become orphan hosts with the root server selected as the one with the lowest root distance. Other non-orphan hosts will synchronize to the root server using normal NTP operations.

    +

    The second scenario includes three secondary servers A, B and C, each normally synchronized to public primary NTP servers or to radio clocks and to the same Ethernet LAN. These servers operate in symmetric modes in a circular topology; active A server is B, active B server is C and active C server is A. Each server is configured with the tos orphan command. While this topology provides a massive degree of redundancy and survivability, the interesting case is when all primary servers are unavailable. The eventual result is the same as the previous scenario; all three servers or orphans and the one with the lowest root delay becomes the root server.

    Burst Modes

    -

    There are two burst modes where a single poll event triggers a burst of eight packets at 2-s intervals instead of the usual one. The burst mode sends a burst when the server is reachable, while the iburst mode sends a burst when the server is unreachable. Each mode is independently of the other and both can be used if necessary. The calldelay command can be used to increase the interval between the first and second packets in the burst in order to allow a modem to complete a call. Received server packets update the clock filter, which selects the best (most accurate) time values. When the last packet in the burst is sent, the next received packet updates the system variables and sets the system clock in the usual manner, as if only a single client/server cycle had occurred. The result is not only a rapid and reliable setting of the system clock, but a considerable reduction in network jitter.

    +

    There are two burst modes where a single poll event triggers a burst of eight packets at 2-s intervals instead of the normal poll interval. The burst mode sends a burst when the server is reachable, while the iburst mode sends a burst when the server is unreachable. Each mode is independently of the other and both can be used if necessary. The calldelay command can be used to increase the interval between the first and second packets in the burst in order to allow a modem to complete a call, for instance. Received server packets update the clock filter, which selects the best (most accurate) time values. When the last packet in the burst is sent, the next received packet updates the system variables and sets the system clock in the usual manner, as if only a single client/server cycle had occurred. The result is not only a rapid and reliable setting of the system clock, but a considerable reduction in network jitter.

    The iburst keyword is used where it is important to set the clock quickly when an association is first mobilized or first becomes reachable or when the network attachment requires an initial calling or training procedure. The burst is initiated only when the server first becomes reachable and results in good accuracy with intermittent connections typical of PPP and ISDN services. Outlyers due to initial dial-up delays, etc., are avoided and the client sets the clock within a few seconds after the first message.

    -

    The burst keyword can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training procedure. The burst is initiated at each poll interval when the server is reachable. The burst does produce additional network overhead and can cause trouble if used indiscriminately. It should only be used where the poll interval is expected to settle to values at or above 1024 s.

    +

    The burst keyword can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training procedure. The burst is initiated at each poll interval when the server is reachable. The burst does produce additional network overhead and can cause trouble if used indiscriminately. In general, It should only be used where the poll interval is expected to settle to values at or above 1024 s.

    diff --git a/html/index.html b/html/index.html index d41a2f6e3d..9db42d332a 100644 --- a/html/index.html +++ b/html/index.html @@ -13,7 +13,7 @@

    The Network Time Protocol (NTP) Distribution

    gifP.T. Bridgeport Bear; from Pogo, Walt Kelly

    Pleased to meet you.

    -

    Last update: 03:09 UTC Friday, June 22, 2007

    +

    Last update: 02:59 UTC Tuesday, August 14, 2007


    Related Links

    @@ -31,12 +31,12 @@

    Introduction

    Note: The software contained in this distribution is available without charge under the conditions set forth in the Copyright Notice.

    -

    The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides accuracies typically within a millisecond on LANs and up to a few tens of milliseconds on WANs relative to Coordinated Universal Time (UTC) via a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability.

    -

    This software release implements NTP Version 4 (NTPv4), but is in general backwards compatible with previous versions except NTP Version 1, support for which is no longer viable. NTPv4 includes support for both symmetric key and public key cryptography to prevent accidental or malicious protocol attacks, as well as automatic server discovery using IP multicast means. This release includes full support for the IPv6 address family, where the operating system supports it, as well as the default IPv4 address family. Either or both families can be used at the same time on the same machine.

    -

    Background information on computer network time synchronization can be found on the Executive Summary - Computer Network Time Synchronization page. Discussion on protocol conformance issues and interoperability with previous NTP versions can be found on the Protocol Conformance Statement page. Discussion on how NTP reckons the time can be found on the NTP Timescale and Leap Seconds page. Background information, bibliography and briefing slides suitable for presentations can be found on the Network Time Synchronization Project page. Additional information can be found at the NTP web site www.ntp.org. Please send bug reports to <bugs@mail.ntp.org>.

    +

    The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides accuracies typically less than a millisecond on LANs and up to a few milliseconds on WANs relative to a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability.

    +

    This software release implements NTP Version 4 (NTPv4), but is in general backwards compatible with previous versions except NTP Version 1, support for which is no longer viable. NTPv4 includes support for both symmetric key and public key cryptography to prevent accidental or malicious protocol attacks, as well as automatic server discovery using IP multicast means. This release includes full support for the IPv6 address family, where the operating system supports it, as well as the IPv4 address family. Either or both families can be used at the same time on the same machine.

    +

    Background information on computer network time synchronization can be found on the Executive Summary - Computer Network Time Synchronization page. Discussion on protocol conformance issues and interoperability with previous NTP versions can be found on the NTP Version 4 Release Notes page. Discussion on how NTP reckons the time can be found on the NTP Timescale and Leap Seconds page. Background information, bibliography and briefing slides suitable for presentations can be found on the Network Time Synchronization Project page. Additional information can be found at the NTP web site www.ntp.org. Please send bug reports to <bugs@ntp.org>.

    Building and Installing NTP

    NTP supports Unix and Windows (XP, NT4 and 2000) systems. The Building and Installing the Distribution page presents an overview of the procedures for compiling the distribution and installing it on a typical client or server. The build procedures inspect the system hardware and software environment and automatically select the appropriate options for that environment. While these procedures work with most computers and operating systems marketed today, exceptions requiring manual intervention do exist, as documented on the Configuration Options and Release Notes pages.

    -

    Bringing up a NTP primary server requires a radio or satellite receiver or modem. The distribution includes hardware drivers for some forty radio and satellite clocks and modem services. A list of supported drivers is given on the Reference Clock Drivers page. It is also possible to use an otherwise undisciplined machine as a primary or backup server, as described on the Undisciplined Local Clock page. For most popular workstations marketed by Sun, Silicon Graphics and Hewlett Packard, as well as widely available Unix clones such as FreeBSD and Linux, the automatic build procedures select all drivers that run on the target machine. While this increases the size of the executable binary somewhat, individual drivers can be included or excluded using the configure utility documented in the Configuration Options page.

    +

    Bringing up a NTP primary server requires a radio or satellite receiver or modem. The distribution includes hardware drivers for over 40 radio and satellite receivers and modem services in both the US and Europe. A list of supported drivers is given on the Reference Clock Drivers page. It is also possible to use an otherwise undisciplined machine as a primary or backup server, as described on the Undisciplined Local Clock page. For most popular workstations marketed by Sun, Silicon Graphics and Hewlett Packard, as well as widely available Unix clones such as FreeBSD and Linux, the automatic build procedures select all drivers that run on the target machine. While this increases the size of the executable binary somewhat, individual drivers can be included or excluded using the configure utility documented in the Configuration Options page.

    Some programs included in this distribution use cryptographic algorithms to verify authenticity and credentials. Where local security policy permits relatively weak symmetric key cryptography, the required software is included in this distribution. However, where local policy requires stronger public key cryptography, additional software not in this distribution is required. This distribution uses the OpenSSL library available from http://www.openssl.org. This library is also used by the Secure Shell facility, so is often already installed on Unix workstations and servers. It includes support for most message digest and digital signature algorithms used in the industry, as well as X.509 certificate generation, signing and verification.

    While public key cryptography is optional but highly recommended for all NTP operations, it is required for the NTPv4 Autokey protocol described on the Autonomous Authentication page and is an integral component of the generic automatic configuration scheme described on the Autonomous Configuration page. In addition, access can be restricted in various ways described on the Access Control Options page.

    Configuring Clients and Servers

    @@ -44,7 +44,7 @@

    However, in order to participate in the existing NTP synchronization subnet and obtain accurate, reliable time, it is usually necessary to construct an appropriate configuration file, commonly called ntp.conf, which establishes the servers and/or external receivers or modems to be used by this particular machine. Directions for constructing this file are in the Notes on Configuring NTP and Setting up a NTP Subnet page. However, in many common cases involving simple network topologies and workstations, the configuration data can be specified entirely on the command line for the ntpd - Network Time Protocol (NTP) daemon.

    The most important factor in providing accurate, reliable time is the selection of modes and servers to be used in the configuration file. A discussion on the available modes is on the Association Management page. NTP support for one or more computers is normally engineered as part of the existing public NTP synchronization subnet. The public subnet consists of a multiply redundant hierarchy of servers and clients, with each level in the hierarchy identified by stratum number. Primary servers operate at stratum one and provide synchronization to secondary servers operating at stratum two and so on to higher strata. In this hierarchy, clients are simply servers that have no dependents.

    Configuring a corporate or campus NTP subnet can be an engineering challenge. NTP contains many features designed to survive system and network failures, software bugs, clock errors and hacker attacks. Surviving these hazards requires intricate design of the timekeeping network using good principles of server redundancy and path diversity. The Manycast mode, new to NTPv4, is designed to track the current server and network states and adjust the client/server configuration for the best available accuracy and reliability. More information on the Manycast mode is on the Athentication Options and Automatic NTP Configuration Options pages.

    -

    The NTP subnet in early 2003 includes well over a hundred public primary (stratum 1) servers synchronized directly to UTC by radio, satellite or modem and located in every continent of the globe, including Antarctica. Normally, client workstations and servers with a relatively small number of clients do not synchronize to primary servers. There are well over a hundred public secondary (stratum 2) servers synchronized to the primary servers and providing synchronization to a total well over 100,000 clients and servers in the Internet. The current lists are maintained on the Information on Time and Frequency Services page, which is updated frequently. There are thousands upon thousands of private primary and secondary servers not normally available to the public, many hiding behind firewalls. Clients are strongly discouraged against using these servers, since they sometimes hide in little ghettos behind dinky links to the outside world and unwanted traffic can bring up expensive ISDN lines, causing much grief and frustration. There are defensive means described on the Access Control Options page, including the Kiss-of-Death packet.

    +

    The NTP subnet in 2007 includes several hundred public primary (stratum 1) servers synchronized directly to UTC by radio, satellite or modem and located in every continent of the globe, including Antarctica. Normally, client workstations and servers with a relatively small number of clients do not synchronize to primary servers. There are several hundred public secondary (stratum 2) servers synchronized to the primary servers and providing synchronization to a total population estimated at over 25 million clients and servers in the public Internet. The current lists are maintained on the Information on Time and Frequency Services page, which is updated frequently. There are thousands upon thousands of private primary and secondary servers not normally available to the public, many hiding behind firewalls. Clients are strongly discouraged to use these servers, since they sometimes hide in little ghettos behind dinky links to the outside world and unwanted traffic can bring up expensive ISDN lines, causing much grief and frustration. There are defensive means described on the Access Control Options page, including the Kiss-of-Death packet.

    Resolving Problems

    Like other things Internet, the NTP synchronization subnets tend to be large and devilishly intricate, with many opportunities for misconfiguration and network problems. The NTP engineering model is specifically designed to help isolate and repair such problems using an integrated management protocol, together with a suite of monitoring and debugging tools. There is an optional statistics data recording facility which can be used to record normal and aberrant operation, log problems to the system log facility, and retain records of client access. The NTP Debugging Techniques and Hints and Kinks pages contain useful information for identifying problems and devising solutions. In extreme cases, problems can be detected through the use of the ntpdsim - Network Time Protocol (NTP) simulator included in this software distribution.

    Users are requested to report bugs, offer suggestions and contribute additions to this distribution. The Patching Procedures page suggests procedures which greatly simplify distribution updates, while the Porting Hints page suggest ways to make porting this code to new hardware and operating systems easier. Additional information on reference clock driver construction and debugging can be found in the Debugging Hints for Reference Clock Drivers page.

    diff --git a/html/release.html b/html/release.html index b2f4d054e8..8159e1a52d 100644 --- a/html/release.html +++ b/html/release.html @@ -13,21 +13,19 @@

    NTP Version 4 Release Notes

    giffrom Alice's Adventures in Wonderland, Lewis Carroll

    The rabbit toots to make sure you read this

    -

    Last update: 19:17 UTC Monday, October 10, 2005

    +

    Last update: 03:05 UTC Tuesday, August 14, 2007

    .

    NTP Version 4 Release Notes

    -

    This release of the NTP Version 4 (NTPv4) daemon for Unix, VMS and Windows incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms. However, it continues the tradition of retaining backwards compatibility with older versions, including NTPv3 and NTPv2, but not NTPv1. Support for NTPv1 has been discontinued because of certain security vulnerabilities. The NTPv4 version has been under development for quite a while and isn't finished yet. In fact, quite a number of NTPv4 features have already been retrofitted in the older NTPv3, although this version is not actively maintained by the NTPv4 developer corps.

    -

    The code compiles and runs properly in all test host configurations available to the developer corps, including Sun Microsystems, Digital/Compaq, Hewlett Packard, FreeBSD and Linux. Other volunteers have verified it works in IRIX and Windows NT and XP. We invite comments and corrections about the various architectures, operating systems and hardware complement that can't be verified by the developer corps. Of particular interest are other Windows versions, VMS and various reference clock drivers. As always, corrections and bugfixes are warmly received, especially in the form of context diffs sent to bugs@ntp.org.

    -

    This release has been compiled and tested on many systems, including SunOS 4.1.3, Solaris 2.5.1-2.10, Alpha Tru64 4.0-5.1, Ultrix 4.4, Linux 2.4.2, FreeBSD 4.5-5.3 and HP-UX 10.02. It has been compiled and tested by others on Windows NT4, 2000 and XP, but not yet on other Windows versions or for VMS. There are several new features apparently incompatible with Linux systems, including some modes used with the Autokey protocol. The developer corps looks for help elsewhere to resolve these differences.

    -

    This note summarizes the differences between this software release of NTPv4, called ntp-4.x.x, and the previous NTPv3 version, called xntp3-5.x.x. Additional information on protocol compatibility details is on the Protocol Conformance Statement page.

    +

    This release of the NTP Version 4 (NTPv4) daemon for Unix, VMS and Windows incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms. However, it continues the tradition of retaining backwards compatibility with older versions, including NTPv3 and NTPv2, but not NTPv1. Support for NTPv1 has been discontinued because of certain security vulnerabilities. The NTPv4 version has been under development for quite a while and isn't finished yet.

    +

    The code compiles and runs properly in all test host configurations available to the developer corps, including Sun Microsystems, Digital/Compaq/Hewlett Packard, FreeBSD and Linux. Other volunteers have verified it works in IRIX and Windows NT and XP. We invite comments and corrections about the various architectures, operating systems and hardware complement that can't be verified by the developer corps. Of particular interest are other Windows versions, VMS and various reference clock drivers. As always, corrections and bugfixes are warmly received, especially in the form of context diffs sent to bugs@ntp.org.

    +

    This release has been compiled and tested on many systems, including SunOS 4.1.3, Solaris 2.5.1-2.10, Alpha Tru64 4.0-5.1, Ultrix 4.4, Linux 2.4.2, FreeBSD 4.5-6.2 and HP-UX 10.02. It has been compiled and tested by others on Windows NT4, 2000 and XP, but not yet on other Windows versions or for VMS. There are several new features apparently incompatible with Linux systems, including some modes used with the Autokey protocol. The developer corps looks for help elsewhere to resolve these differences.

    +

    This note summarizes the differences between this software release of NTPv4, called ntp-4.x.x, and the previous NTPv3 version, called xntp3-5.x.x.

    New Features

      -
    1. Support for the IPv6 addressing family is included in this distribution. If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is detected, support for the IPv6 address family is generated in addition to the default support for the IPv4 address family. Combination IPv6 and IPv4 configurations have been successfully tested in all protocol modes supported by NTP and using both symmetric and public key (Autokey) cryptography. However, users should note that IPv6 support is new and we have not had a lot of experience with it in various operational scenarios and local infrastructure environments. As always, feedback is welcome. -
    2. Most calculations are now done using 64-bit floating double format, rather than 64-bit fixed point format. The motivation for this is to reduce size, improve speed and avoid messy bounds checking. Workstations of today are much faster than when the original NTP version was designed in the early 1980s, and it is rare to find a processor architecture that does not support floating double. The fixed point format is still used with raw timestamps, in order to retain the full precision of about 212 picoseconds. However, the algorithms which process raw timestamps all produce fixed point differences before converting to floating double. The differences are ordinarily quite small so can be expressed without loss of accuracy in this format. +
    3. Support for the IPv6 addressing family is included in this distribution. If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is detected, support for the IPv6 address family is generated in addition to the default support for the IPv4 address family. Combination IPv6 and IPv4 configurations have been successfully tested in all protocol modes supported by NTP and using both symmetric and public key (Autokey) cryptography.
    4. Most calculations are now done using 64-bit floating double format, rather than 64-bit fixed point format. The motivation for this is to reduce size, improve speed and avoid messy bounds checking. Workstations of today are much faster than when the original NTP version was designed in the early 1980s, and it is rare to find a processor architecture that does not support floating double. The fixed point format is still used with raw timestamps, in order to retain the full precision of about 212 picoseconds. However, the algorithms which process raw timestamps all produce fixed point differences before converting to floating double. The differences are ordinarily quite small so can be expressed without loss of accuracy in this format. -
    5. The clock discipline algorithm has been redesigned to improve accuracy, reduce the impact of network jitter and allow increased in poll intervals to well over one day with only moderate sacrifice in accuracy. -
    +
  • The clock discipline algorithm has been redesigned to improve accuracy, reduce the impact of network jitter and allow increased in poll intervals to 36 hours with only moderate sacrifice in accuracy.