Make sure who your friends are.
Last update:
This page describes the automatic server discovery schemes provided in NTPv4. Details about the configuration commands and options are described on the Configuration Options page. Details about the cryptographic authentication schemes are described on the Authentication Options page. Details about the other modes not directly involved in these schemes are described on the Association Management page. Additional information is available in the papers, reports, memoranda and briefings on the NTP Project page.
There are three automatic server discovery schemes: broadcast/multicast, manycast and server pool described on this page. The broadcast/multicast and manycast schemes utilize the ubiquitous broadcast or one-to-many paradigm native to IPv4 and IPv6. The server pool scheme uses DNS to resolve addresses of multiple volunteer servers scattered throughout the world. All three schemes work in much the same way and might be described as grab-n'-drop. Through one means or another they grab at least the number of potential servers specified by the tos maxclock configuration command, order them from best to worst using the NTP algorithms, then cast off from the end of the list until no more than the number of survivors specified in the tos minclock command remain.
This process is handled using a set of counters, one for each preemptible association. Once each poll interval the counter is increased by one. It the counter reaches a cutoff value of 10, it is preempted and demobilized. However, the counters for the survivors at the beginning of the list are set to zero.
Any of the schemes can use a stratum filter to select just those servers with stratum considered useful. This can avoid large numbers of clients ganging up on a small number of low-stratum servers and avoid servers above a certain stratum level. The range of acceptable strata range from the number specified by the tos floor command, inclusive, to the number specified by the tos ceiling command, exclusive. Potential servers operating at the same stratum as the client will be avoided unless the tos cohort command is present.
Since an intruder can impersonate a broadcast or multicast server and inject false time values, broadcast mode should always be cryptographically authenticated.
Following is a summary of each scheme. Note that reference to option applies to the commands described on the Configuration Options page. See that page for applicability and defaults.
A broadcast server generates messages continuously at intervals by default 64 s and time-to-live by default 127. These defaults can be overriden by the minpoll and ttl options, respectively. Not all kernels support the ttl command. A broadcast client responds to the first message received by waiting a randomized interval to avoid implosion at the server. It then polls the server in client/server mode and using the iburst opion in order to quickly authenticate the server, set the host clock and calibrate the broadcast message propagation delay. This normally results in a volley of six client/server exchanges at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently.
Following the volley, the server continues in listen-only mode and sends no further messages. If for some reason the broadcast server does not respond to these messages, the client will cease transmission and continue in listen-only mode with a default propagation delay. The volley can be avoided by using the authdelay configuration command with nonzero argument.
A server is configured in broadcast mode using the broadcast command and specifying the broadcast address of a local interface. If two or more local interfaces are installed with different broadcast addresses, a broadcast command is needed for each address. This provides a way to limit exposure in a firewall, for example. A broadcast client is configured using the broadcastclient command.
NTP multicast mode can be used to extend the scope of a timekeeping using IPv4 multicast or IPv6 broadcast with defined span. The IANA has assigned IPv4 multicast address 224.0.1.1 and IPv6 address 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 specifying a multicast address instead of a broadcast address. A multicast client is configured using the multicastclient command specifying a list of one or more multicast addresses. Note that there is a subtle distinction between the IPv4 and IPv6 address families. The IPv4 broadcast or mulitcast mode is determined by the IPv4 class. For IPv6 the same distinction can be made using the link-local prefix FF02 for each interface and site-local prefix FF05 for all interfacesl.
In both broadcast and multicast versions the client association is demobilized in case of timeout.
Manycast is a automatic server discovery and configuration paradigm new to NTPv4. It is intended as a means for a client to troll the nearby network neighborhood to find cooperating servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. It uses the grab-n'-drop paradigm with the additional feature that active means are used to grab additional servers should the number of survivors fall below the minclock threshold.
The manycast paradigm is not the anycast paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycast paradigm is designed to find a plurality of redundant servers satisfying defined optimality criteria.
A manycast clients is configured using the manycastclient configuration command, which is similar to the server configuration command. It sends ordinary client mode messages, but with a broadcast address rather than a unicast address and sends only if less than minclock survivors remain and then only at the minimum feasible rate and minimum feasible time-to-live (TTL) hops. The polling strategy is designed to reduce as much as possible the volume of broadcast messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. There can be as many manycast client associations as different addresses, each one serving as a template for a future unicast client/server association.
A manycast server is configured using the manycastserver command, which listens on the specified broadcast address for manycast client messages. If a manycast server is in scope of the current TTL and is itself synchronized to a valid source and operating at a stratum level equal to or lower than the manycast client, it replies with an ordinary unicast server message.
The manycast client receiving this message mobilizes a preemptable client association according to the matching manycast client template, but only if cryptographically authenticated and the server stratum is less than or equal to the client stratum.
It is possible and frequently useful to configure a host as both manycast client and manycast server. A number of hosts configured this way and sharing a common group address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance.
The idea of targeting servers on a random basis to distribute and balance the load is not a new one; however, the NTP pool scheme puts this on steroids. At present, several hundred operators around the globe have volunteered their servers for public access. In general, NTP is a lightweight service and servers used for other purposes don't mind an additional small load. The trick is to randomize over the population and minimize the load on any one server while retaining the advantages of multiple servers with the NTP mitigation algorithms.
To support this service the DNS for some volunteer servers as been modified to collect a number of the volunteer servers and return a randomized list in response to a query. The client receiving this list modbilizes some or all of them just as in the other discovery schemes and casts off the excess.
The pool scheme is configured using one or pool commands with the DNS name region.pool.ntp.org, where region is a region of the world, country of the region or state of the country or even the whole world if absent. The pool command can be used more than once; duplicate servers are detected and discarded. In principle, it is possible to use a configuration file containing a single line pool.ntp.org.