RFC 2030
Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
RFC 2030: Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI 🎀
okay so here's the deets, bestie 💅
- Group: Network Working Group
- Author: D. Mills, University of Delaware
- Date: October 1996
- Category: Informational
- Obsoletes: RFC 1769 (SNTP Version 3) 🫶
Part 1 of 5 🧚
Status of this Memo ✨
okay so this memo is just information for the Internet community 🌸 it does not specify an Internet standard of any kind, so it's not a rulebook, it's more of a friendly heads-up. distribution of this memo is unlimited, so share it with everyone 💖
Abstract 💜
okay bestie, this doc describes the Simple Network Time Protocol (SNTP) Version 4, which is basically a lighter version of the Network Time Protocol (NTP) that people use to keep computer clocks synced across the Internet ⏰ SNTP is perfect when you don't need the ultimate performance of the full NTP implementation from RFC-1305, aka you don't need it to be extra extra 💅
when it's working with current and previous NTP and SNTP versions, SNTP Version 4 doesn't change the NTP spec or the known implementations at all 🙈 instead it just clarifies some design features of NTP so it can work in a simple, stateless remote-procedure call (RPC) mode. the accuracy and reliability are similar to the UDP/TIME protocol from RFC-868, which is giving very reliable vibes ✨
the only big protocol change in SNTP Version 4 (compared to earlier NTP and SNTP) is a modified header interpretation so it can handle IPv6 [DEE96] and OSI [COL94] addressing 🦋 it also has some optional extras on top of the basic Version 3 model, including an anycast mode and an authentication scheme made specifically for multicast and anycast modes 🔥 the anycast mode extension is described in this document, but the authentication scheme will get its own document later. until that definitive spec comes out, these extensions should be considered provisional, so don't get too attached yet 🥺
this memo obsoletes RFC-1769, which described SNTP Version 3. the goal is to fix some inconsistencies in the previous doc and clarify the header formats and protocol operations for the current NTP Version 3 (IPv4) and the proposed NTP Version 4 (IPv6 and OSI), which SNTP uses too 🌈 and the lowkey best part: you don't need a working knowledge of the NTP Version 3 spec from RFC-1305 to implement SNTP 💖
1. Introduction ✨
okay so the Network Time Protocol (NTP) Version 3, specified in RFC-1305 [MIL92], is seriously popular for syncing computer clocks all over the global Internet 🌍 it has comprehensive mechanisms to access national time and frequency dissemination services, organize the time-synchronization subnet, and adjust the local clock in each participating subnet peer. it's giving "full-service spa day" 💅 today, NTP gets accuracies of 1-50 ms, depending on the synchronization source and the network paths 🍓
RFC-1305 describes the NTP Version 3 protocol machine in terms of events, states, transition functions and actions. it also has engineered algorithms that improve timekeeping quality and help sort things out between several synchronization sources, some of which might be faulty 🫠 to get accuracies in the low milliseconds across big chunks of the Internet, those intricate algorithms (or their functional equivalents) are necessary 🧠 but in lots of cases, accuracies in the order of significant fractions of a second are totally fine ✨ for those, simpler protocols like the Time Protocol [POS83] have been used. these usually involve an RPC exchange where the client asks for the time of day and the server sends it back in seconds past some known reference epoch 🕰️
NTP is built for clients and servers with a wide range of capabilities, over a wide range of network delays and jitter characteristics 🌊 most people on the Internet NTP sync subnet use a software package with the full suite of NTP options and algorithms. those are relatively complex, real-time applications (see http://www.eecis.udel.edu/~ntp) 📚 the software has been ported to a wide variety of hardware platforms, from personal computers all the way up to supercomputers, but its sheer size and complexity isn't appropriate for many applications 💀 so it makes sense to explore alternative access strategies using simpler software that fits less stringent accuracy expectations 🍓
this document describes the Simple Network Time Protocol (SNTP) Version 4, a simplified access strategy for servers and clients using NTP Version 3 (as it's now specified and deployed on the Internet) and NTP Version 4 (which is still under development) 🦋 the access paradigm is identical to the UDP/TIME Protocol. in fact, it should be easily possible to adapt a UDP/TIME client implementation, say for a personal computer, to operate using SNTP 🎀 SNTP is also designed to run in a dedicated server configuration that includes an integrated radio clock. with careful design and control of the various latencies in the system (which is practical in a dedicated design), it's possible to deliver time accurate to the order of microseconds 🤯 iconic.
SNTP Version 4 is designed to coexist with existing NTP and SNTP Version 3 clients and servers, as well as proposed Version 4 clients and servers 🫶 when it's operating with current and previous versions of NTP and SNTP, SNTP Version 4 requires no changes to the protocol or to the implementations running now or likely to be built specifically for NTP in SNTP Version 4 ✨ to an NTP or SNTP server, NTP and SNTP clients are undistinguishable 👀 and to an NTP or SNTP client, NTP and SNTP servers are undistinguishable too 💅 like NTP servers operating in non-symmetric modes, SNTP servers are stateless and can support large numbers of clients. but unlike most NTP clients, SNTP clients normally operate with only a single server 🧚 NTP and SNTP Version 3 servers can operate in unicast and multicast modes, and SNTP Version 4 clients and servers can implement extensions to operate in anycast mode 🌈
it is strongly recommended that SNTP be used only at the extremities of the synchronization subnet 🚨 SNTP clients should operate only at the leaves (highest stratum) of the subnet, and only in configurations where no NTP or SNTP client depends on another SNTP client for synchronization 🙅♀️ SNTP servers should operate only at the root (stratum 1) of the subnet, and then only in configurations where no source of synchronization other than a reliable radio or modem time service is available 📡 the full degree of reliability normally expected of primary servers is only possible using the redundant sources, diverse subnet paths and crafted algorithms of a full NTP implementation 🧠 this extends to the primary source of synchronization itself: you'd want multiple radio or modem sources and backup paths to other primary servers, in case all sources fail or the majority deliver incorrect time 😭 so the use of SNTP rather than NTP in primary servers should be carefully considered 🔥
aside, bestie: an important provision in this document is the reinterpretation of certain NTP Version 4 header fields. these provide IPv6 and OSI addressing and optional anycast extensions designed specifically for multicast service 🎀 these additions go along with the proposed NTP Version 4 specification, which will appear as a separate document 💖 the only difference between the current NTP Version 3 and proposed NTP Version 4 header formats is how the four-octet Reference Identifier field is interpreted. that field is used mainly to detect and avoid synchronization loops 🔁 in Version 3 and Version 4 primary (stratum-1) servers, this field contains the four-character ASCII reference identifier defined later in this document. in Version 3 secondary servers and clients, it contains the 32-bit IPv4 address of the synchronization source. in Version 4 secondary servers and clients, it contains the low order 32 bits of the last transmit timestamp received from the synchronization source 🦋
in the case of OSI, the Connectionless Transport Service (CLTS) is used [ISO86] 🌸 each SNTP packet is transmitted as the TS-Userdata parameter of a T-UNITDATA Request primitive. alternatively, the header can be encapsulated in a TPDU, which itself is transported using UDP [DOB91] 🧚 it is not advised that NTP be operated at the upper layers of the OSI stack, such as might be inferred from [FUR94], because this could seriously degrade accuracy 😬 with the header formats defined in this document, it's in principle possible to interwork between servers and clients of one protocol family and another, although the practical difficulties may make this inadvisable 🫠
aside, bestie: in the following, indented paragraphs such as this one contain information not required by the formal protocol specification, but considered good practice in protocol implementations 💅✨
2. Operating Modes and Addressing ✨
okay so SNTP Version 4 can run in three modes: unicast (point to point), multicast (point to multipoint), or anycast (multipoint to point) 🦋 A unicast client sends a request to a designated server at its unicast address and waits for a reply. From that reply it can work out the time and, optionally, the roundtrip delay and local clock offset relative to the server 💅 A multicast server periodically sends an unsolicited message to a designated IPv4 or IPv6 local broadcast address or multicast group address, and it normally doesn't expect any requests from clients 🌸 A multicast client listens on that address and normally sends no requests at all. An anycast client sends a request to a designated IPv4 or IPv6 local broadcast address or multicast group address. One or more anycast servers reply, each with its own unicast address. The client binds to the first reply it gets and then keeps going in unicast mode 🫶
Multicast servers should respond to client unicast requests, as well as send unsolicited multicast messages. Multicast clients may send unicast requests in order to determine the network propagation delay between the server and client, and then continue operation in multicast mode. 🧚
In unicast mode, the client and server end-system addresses are assigned using the usual IPv4, IPv6 or OSI conventions 💖 In multicast mode, the server uses a designated local broadcast address or multicast group address. An IP local broadcast address has its scope limited to a single IP subnet, since routers do not propagate IP broadcast datagrams 😭 An IP multicast group address, on the other hand, can have a scope reaching potentially the entire Internet 🌈 The scoping, routing and group membership procedures are decided by considerations that are beyond the scope of this document. For IPv4, the IANA has assigned the multicast group address 224.0.1.1 for NTP, and it's used by both multicast servers and anycast clients 🎀 NTP multicast addresses for IPv6 and OSI have yet to be determined.
Multicast clients listen on the designated local broadcast address or multicast group address. With local broadcast addresses, no further provisions are necessary 💅 With IP multicast addresses, the multicast client and anycast server must implement the Internet Group Management Protocol (IGMP) [DEE89], so that the local router joins the multicast group and relays messages to the IPv4 or IPv6 multicast group addresses assigned by the IANA 🔥 Other than the IP addressing conventions and IGMP, there is no difference in server or client operations between the local broadcast address and the multicast group address 👑
It is important to adjust the time-to-live (TTL) field in the IP header of multicast messages to a reasonable value, in order to limit the network resources used by this (and any other) multicast service. Only multicast clients in scope will receive multicast server messages. Only cooperating anycast servers in scope will reply to a client request. The engineering principles that determine the proper value to be used are beyond the scope of this document. 🙈
Anycast mode is designed for use with a set of cooperating servers whose addresses are not known to the client beforehand ✨ An anycast client sends a request to the designated local broadcast or multicast group address, as described below. For this purpose, the NTP multicast group address assigned by the IANA is used. One or more anycast servers listen on the designated local broadcast address or multicast group address. Each anycast server, upon receiving a request, sends a unicast reply message to the originating client. The client then binds to the first such message it receives and continues operation in unicast mode. Replies from other anycast servers after that are ignored 🦋
In the case of SNTP as specified herein, there is a very real vulnerability that SNTP multicast clients can be disrupted by misbehaving or hostile SNTP or NTP multicast servers elsewhere in the Internet, since at present all such servers use the same IPv4 multicast group address assigned by the IANA 💀 Where necessary, access control based on the server source address can be used to select only the designated server that is known to and trusted by the client. The use of the cryptographic authentication scheme defined in RFC-1305 is optional; however, implementors should be advised that extensions to this scheme are planned specifically for NTP multicast and anycast modes. 🚨
While not integral to the SNTP specification, it is intended that IP broadcast addresses will be used primarily in IP subnets and LAN segments that include a fully functional NTP server with a number of dependent SNTP multicast clients on the same subnet 🌸 IP multicast group addresses, meanwhile, will be used only in cases where the TTL is engineered specifically for each service domain.
In NTP Version 3, the reference identifier was often used to walk back the synchronization subnet to the root (primary server) for management purposes. In NTP Version 4, this feature is not available, since the addresses are longer than 32 bits 😭 However, the intent in the protocol design was to provide a way to detect and avoid loops. A peer could determine that a loop was possible by comparing the contents of this field with the IPv4 destination address in the same packet. An NTP Version 4 server can accomplish the same thing by comparing the contents of this field with the low order 32 bits of the originate timestamp in the same packet. There is a small possibility of a false alarm in this scheme, but the false alarm rate can be minimized by randomizing the low order unused bits of the transmit timestamp. 💜
3. NTP Timestamp Format 🕰️
SNTP uses the standard NTP timestamp format described in RFC-1305 and previous versions of that document 🎀 In line with standard Internet practice, NTP data are specified as integer or fixed-point quantities, with bits numbered in big-endian fashion starting from 0 at the left, or high-order, position. Unless specified otherwise, all quantities are unsigned and may occupy the full field width with an implied 0 preceding bit 0.
Since NTP timestamps are cherished data and, in fact, represent the main product of the protocol, a special timestamp format has been established 💖 NTP timestamps are represented as a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part is in the last 32 bits. In the fraction part, the non-significant low order bits can be set to 0 ✨
It is advisable to fill the non-significant low order bits of the timestamp with a random, unbiased bitstring, both to avoid systematic roundoff errors and as a means of loop detection and replay detection (see below). One way of doing this is to generate a random bitstring in a 64-bit word, then perform an arithmetic right shift a number of bits equal to the number of significant bits of the timestamp, then add the result to the original timestamp. 🎲
This format allows convenient multiple-precision arithmetic and conversion to UDP/TIME representation (seconds), but it does complicate the conversion to ICMP Timestamp message representation, which is in milliseconds 🫠 The maximum number that can be represented is 4,294,967,295 seconds, with a precision of about 200 picoseconds, which should be adequate for even the most exotic requirements 🧁
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Fraction (0-padded) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note that, since some time in 1968 (second 2,147,483,648), the most significant bit (bit 0 of the integer part) has been set, and that the 64-bit field will overflow some time in 2036 (second 4,294,967,296) 🚀 Should NTP or SNTP be in use in 2036, some external means will be necessary to qualify time relative to 1900 and time relative to 2036 (and other multiples of 136 years). There will exist a 200-picosecond interval, henceforth ignored, every 136 years when the 64-bit field will be 0, which by convention is interpreted as an invalid or unavailable timestamp 🌙
As the NTP timestamp format has been in use for the last 17 years, it remains a possibility that it will be in use 40 years from now, when the seconds field overflows. As it is probably inappropriate to archive NTP timestamps before bit 0 was set in 1968, a convenient way to extend the useful life of NTP timestamps is the following convention: If bit 0 is set, the UTC time is in the range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1 January 1900. If bit 0 is not set, the time is in the range 2036-2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February 2036. Note that when calculating the correspondence, 2000 is not a leap year. Note also that leap seconds are not counted in the reckoning. 🫶
4. NTP Message Format ✨
okay so bestie, NTP and SNTP are both clients of UDP [POS80] 🦋, and UDP is itself a client of IP [DAR81] 💅. The IP and UDP headers are described in those cited docs, so we're not going to go over them again here 🙈. The UDP port number for NTP is 123, and it should be used in both the Source Port and Destination Port fields in the UDP header 🎀. The other UDP header fields should be set the way the spec describes ✨.
Now for the NTP/SNTP Version 4 message format, which comes right after the IP and UDP headers 🌸. It's the same as what's in RFC-1305, except for what goes in the reference identifier field 👑. Here's how the header fields look:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originate Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transmit Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier (optional) (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Message Digest (optional) (128) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+As the next section explains, most of these fields get filled in with pre-set data in SNTP 🧚. For completeness, here's a quick rundown of what each field does 💖.
Leap Indicator (LI): this is a two-bit code 🚨 warning about an upcoming leap second that will be added or removed in the last minute of the current day. Bit 0 and bit 1 are coded like this:
LI Value Meaning
-------------------------------------------------------
00 0 no warning
01 1 last minute has 61 seconds
10 2 last minute has 59 seconds)
11 3 alarm condition (clock not synchronized)Version Number (VN): this is a three-bit integer for the NTP/SNTP version number 🔢. Version 3 is number 3 (IPv4 only), and Version 4 is number 4 (IPv4, IPv6 and OSI) 🌈. If you need to tell apart IPv4, IPv6 and OSI, the encapsulating context should be inspected 🔍.
Mode: this is a three-bit integer for the mode 🎭, with the values defined like so:
Mode Meaning
------------------------------------
0 reserved
1 symmetric active
2 symmetric passive
3 client
4 server
5 broadcast
6 reserved for NTP control message
7 reserved for private useIn unicast and anycast modes, the client sets this field to 3 (client) in the request, and the server sets it to 4 (server) in the reply 📨. In multicast mode, the server sets this field to 5 (broadcast) 📣.
Stratum: this is an eight-bit unsigned integer for the stratum level of the local clock 🏆. The values are:
Stratum Meaning
----------------------------------------------
0 unspecified or unavailable
1 primary reference (e.g., radio clock)
2-15 secondary reference (via NTP or SNTP)
16-255 reservedPoll Interval: this is an eight-bit signed integer for the maximum gap between successive messages, in seconds to the nearest power of two ⏰. Right now the values that can show up here range from 4 (16 s) to 14 (16284 s) 🕰️. Most applications only use the sub-range 6 (64 s) to 10 (1024 s) 💜.
Precision: this is an eight-bit signed integer for how precise the local clock is, in seconds to the nearest power of two 🎯. The values that normally show up range from -6 for mains-frequency clocks to -20 for microsecond clocks found in some workstations 💻.
Root Delay: this is a 32-bit signed fixed-point number for the total roundtrip delay to the primary reference source, in seconds with the fraction point between bits 15 and 16 🌊. Be careful, because this one can be positive or negative, depending on the relative time and frequency offsets 🙃. The values that normally show up range from negative values of a few milliseconds to positive values of several hundred milliseconds 🫠.
Root Dispersion: this is a 32-bit unsigned fixed-point number for the nominal error relative to the primary reference source, in seconds with the fraction point between bits 15 and 16 🌸. The values that normally show up range from 0 to several hundred milliseconds ✨.
Reference Identifier: this is a 32-bit bitstring that identifies the particular reference source 🆔. For NTP Version 3 or Version 4 stratum-0 (unspecified) or stratum-1 (primary) servers, it's a four-character ASCII string, left justified and zero padded to 32 bits 🔤. In NTP Version 3 secondary servers, it's the 32-bit IPv4 address of the reference source 📍. In NTP Version 4 secondary servers, it's the low order 32 bits of the latest transmit timestamp of the reference source ⏳. NTP primary (stratum 1) servers should set this field to a code that identifies the external reference source, using the list below 📋. If the external reference is one of the listed ones, the matching code should be used 💅. Codes for sources that aren't listed can be contrived as appropriate 🧪.
Code External Reference Source
----------------------------------------------------------------
LOCL uncalibrated local clock used as a primary reference for
a subnet without external means of synchronization
PPS atomic clock or other pulse-per-second source
individually calibrated to national standards
ACTS NIST dialup modem service
USNO USNO modem service
PTB PTB (Germany) modem service
TDF Allouis (France) Radio 164 kHz
DCF Mainflingen (Germany) Radio 77.5 kHz
MSF Rugby (UK) Radio 60 kHz
WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz
WWVB Boulder (US) Radio 60 kHz
WWVH Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz
CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz
LORC LORAN-C radionavigation system
OMEG OMEGA radionavigation system
GPS Global Positioning Service
GOES Geostationary Orbit Environment SatelliteReference Timestamp: this is the time when the local clock was last set or corrected, in 64-bit timestamp format ⏱️.
Originate Timestamp: this is the time when the request left the client for the server, in 64-bit timestamp format 🚀.
Receive Timestamp: this is the time when the request arrived at the server, in 64-bit timestamp format 📬.
Transmit Timestamp: this is the time when the reply left the server for the client, in 64-bit timestamp format 💌.
Authenticator (optional): when the NTP authentication scheme is implemented, the Key Identifier and Message Digest fields hold the message authentication code (MAC) information defined in Appendix C of RFC-1305 🔐🫶.
5. SNTP Client Operations ✨
okay bestie, so an SNTP client can run in three modes 🦋: multicast, unicast, or anycast. In multicast mode the client sends nothing and just waits for a broadcast (mode 5) from a designated multicast server. In unicast mode it sends a request (mode 3) to one designated unicast server and expects a reply (mode 4) back from that same server. In anycast mode it sends a request (mode 3) to a designated local broadcast or multicast group address and expects a reply (mode 4) from one or more anycast servers. The client takes the first reply it gets and locks in that server for later unicast operations. After that, any later replies from that server (duplicates) or from any other server get ignored 🙈. Apart from which address goes in the request, anycast and unicast clients work exactly the same way 💅. Requests are normally sent every 64 s to 1024 s, depending on how wobbly the client clock's frequency tolerance is and how accurate you need to be 🕰️
Unicast and anycast clients basically do three things: set up the NTP message header, send the request to the server, and pull the time of day out of the Transmit Timestamp field of the reply 🎀. For this, every NTP header field shown above can be set to 0, except the first octet and the (optional) Transmit Timestamp field. In that first octet, the LI field is set to 0 (no warning) and the Mode field is set to 3 (client) 🌸. The VN field has to agree with the version number of the NTP/SNTP server. BUT, Version 4 servers will also accept previous versions, which is very generous of them 🫶. Version 3 (RFC-1305) and Version 2 (RFC-1119) servers already accept all the previous versions, including Version 1 (RFC-1059). And Version 0 (RFC-959)? Not supported by any other version anymore, so it's giving retired 💀
Since NTP and SNTP servers of all four versions are probably going to keep interoperating on the Internet, you should think carefully about which version your SNTP Version 4 client uses 🧚. It's recommended that clients use the latest version the selected server is known to support, for the highest accuracy and reliability ✨. SNTP Version 4 clients can talk to every previous-version NTP and SNTP server, because the header fields SNTP clients use haven't changed at all 🦋. Version 4 servers are required to reply in the same version as the request, so the VN field of the request also tells you the version of the reply. Main character energy from the request, honestly 👑
Now, the transmit timestamp. It isn't strictly necessary for a conforming client implementation, but in unicast and anycast modes it's highly recommended that the transmit timestamp in the request is set to the client's time of day in NTP timestamp format 🍓. Why? It makes it easy to work out the propagation delay between server and client, it helps line up your local clock to within a few tens of milliseconds of the server, and it gives you a simple way to check that a reply is really a legit response to your request and not a replay 🔥. In multicast mode, the client has no info to work out the propagation delay or check whether the server is valid, unless the NTP authentication scheme is being used 🔐
To work out the roundtrip delay d and the local clock offset t relative to the server, the client puts its time of day (in NTP timestamp format) into the transmit timestamp of the request. The server copies that field into the originate timestamp of the reply, then sets the receive timestamp and transmit timestamp to its time of day in NTP timestamp format 💜. It's giving mirror, honestly 🪞
When the server's reply comes back, the client works out a Destination Timestamp, which is its own clock's time of arrival in NTP timestamp format 🌈. Here's the whole timestamp lineup in one place:
Timestamp Name ID When Generated
------------------------------------------------------------
Originate Timestamp T1 time request sent by client
Receive Timestamp T2 time request received by server
Transmit Timestamp T3 time reply sent by server
Destination Timestamp T4 time reply received by clientAnd the math, bestie 🧮:
d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.Now the checklist. The table below shows the SNTP client operations for unicast, anycast and multicast modes. The recommended error checks are in the Reply and Multicast columns 🔍. A message should be considered valid only if all the fields shown contain values in their respective ranges. If one or more of the fields marked "ignore" have invalid values, whether you still believe the message is up to the implementation 🤷♀️
Field Name Unicast/Anycast Multicast
Request Reply
----------------------------------------------------------
LI 0 0-2 0-2
VN 1-4 copied from 1-4
request
Mode 3 4 5
Stratum 0 1-14 1-14
Poll 0 ignore ignore
Precision 0 ignore ignore
Root Delay 0 ignore ignore
Root Dispersion 0 ignore ignore
Reference Identifier 0 ignore ignore
Reference Timestamp 0 ignore ignore
Originate Timestamp 0 (see text) ignore
Receive Timestamp 0 (see text) ignore
Transmit Timestamp (see text) nonzero nonzero
Authenticator optional optional optional6. SNTP Server Operations ✨
Okay bestie, a SNTP Version 4 server that's chatting with an NTP or SNTP client (same version or an older one) keeps NO persistent state 💅 Real talk though, a SNTP server doesn't run the full NTP algorithm set, which is the stuff built for redundant peers and diverse network paths 🌈 So it SHOULD only be operated alongside an external source of synchronization, like a reliable radio clock or a telephone modem. When it is, it always operates as a primary (stratum 1) server 👑
A SNTP server can operate in unicast mode, anycast mode, multicast mode, or any combination of these modes 🦋 In unicast and anycast modes, the server receives a request (mode 3), tweaks certain fields in the NTP header, and sends back a reply (mode 4), possibly reusing the same message buffer as the request. In anycast mode, the server listens on the designated local broadcast or multicast group address assigned by the IANA, but it uses its own unicast address in the source address field of the reply. Other than picking that address for the reply, anycast and unicast servers work exactly the same 🫶 Multicast messages are normally sent at poll intervals from 64 s to 1024 s, depending on the expected frequency tolerance of the client clocks and the required accuracy.
In unicast and anycast modes, the VN and Poll fields of the request get copied intact into the reply ✨ If the Mode field of the request is 3 (client), it gets set to 4 (server) in the reply. Otherwise, it's set to 2 (symmetric passive) so it matches the NTP specification. This lets clients configured in symmetric active (mode 1) interoperate successfully, even if they were set up in possibly suboptimal ways 🙈 In multicast (unsolicited) mode, the VN field is set to 4, the Mode field is set to 5 (broadcast), and the Poll field is set to the nearest integer base-2 logarithm of the poll interval.
Note that it is highly desirable that, if a server supports multicast mode, it also supports unicast mode. This is so a potential multicast client can calculate the propagation delay using a client/server exchange prior to regular operation using only multicast mode. If the server supports anycast mode, then it MUST support unicast mode. There does not seem to be a great advantage to operate both multicast and anycast modes at the same time, although the protocol specification does not forbid it.
In unicast and anycast modes, the server MAY or MAY NOT respond if it isn't synchronized to a correctly operating radio clock. The preferred option is to respond, though, since that lets reachability be determined regardless of synchronization state 💜 In multicast mode, the server sends broadcasts only if it's synchronized to a correctly operating reference clock.
The remaining fields of the NTP header get set like this. Assuming the server is synchronized to a radio clock or other primary reference source and operating correctly, the LI field is set to 0 and the Stratum field is set to 1 (primary server). If not, the Stratum field is set to 0 and the LI field is set to 3. The Precision field is set to reflect the maximum reading error of the local clock. For all practical cases, it's computed as the negative of the number of significant bits to the right of the decimal point in the NTP timestamp format. The Root Delay and Root Dispersion fields are set to 0 for a primary server. Optionally, the Root Dispersion field can be set to a value corresponding to the maximum expected error of the radio clock itself. The Reference Identifier is set to designate the primary reference source, as indicated in the table of Section 5 of this document 🍓
The timestamp fields are set as follows 🎀 If the server is unsynchronized or first coming up, all timestamp fields are set to zero. If it's synchronized, the Reference Timestamp is set to the time the last update was received from the radio clock or modem. In unicast and anycast modes, the Receive Timestamp and Transmit Timestamp fields are set to the time of day when the message is sent, and the Originate Timestamp field is copied unchanged from the Transmit Timestamp field of the request. It is important that this field be copied intact, as a NTP client uses it to avoid replays 🔥 In multicast mode, the Originate Timestamp and Receive Timestamp fields are set to 0, and the Transmit Timestamp field is set to the time of day when the message is sent. Here's the table that sums all of this up:
Field Name Unicast/Anycast Multicast
Request Reply
----------------------------------------------------------
LI ignore 0 or 3 0 or 3
VN 1-4 copied from 4
request
Mode 3 2 or 4 5
Stratum ignore 1 1
Poll ignore copied from log2 poll
request interval
Precision ignore -log2 server -log2 server
significant significant
bits bits
Root Delay ignore 0 0
Root Dispersion ignore 0 0
Reference Identifier ignore source ident source ident
Reference Timestamp ignore time of last time of last
radio update radio update
Originate Timestamp ignore copied from 0
transmit
timestamp
Receive Timestamp ignore time of day 0
Transmit Timestamp (see text) time of day time of day
Authenticator optional optional optionalThere's some latitude on most clients to forgive invalid timestamps, like the ones that might pop up when a server is first coming up or while the primary reference source is down 😭 The most important sign of an unhealthy server is the LI field, where a value of 3 indicates an unsynchronized condition. When this value is displayed, clients SHOULD discard the server message, regardless of the contents of the other fields. Not the vibe, so bye 💀
7. Configuration and Management
Initial setup for SNTP servers and clients can be done with a configuration file if a file system is available, or through a serial port if it isn't 🧚 In-service management of NTP and SNTP Version 4 servers and clients is intended to be done using SNMP and a suitable MIB that will be published later. Ordinarily, SNTP servers and clients are expected to run with little or no site-specific configuration, other than specifying the IP address and subnet mask or OSI NSAP address 🌸
Unicast clients MUST be provided with the designated server name or address. If a server name is used, the address of one or more DNS servers MUST be provided. Multicast servers and anycast clients MUST be provided with the TTL and local broadcast or multicast group address. Anycast servers and multicast clients MAY be configured with a list of address-mask pairs for access control, so that only the clients or servers known to be trusted will be used. These servers and clients MUST implement the IGMP protocol and MUST be provided with the local broadcast or multicast group address as well. The configuration data for cryptographic authentication is beyond the scope of this document 🔐
There are several scenarios that give SNTP clients automatic server discovery and selection with no pre-specified configuration, other than the IP address and subnet mask or OSI NSAP address ✨ For an IP subnet or LAN segment that includes a fully functional NTP server, clients can be configured for multicast mode using the local broadcast address. The same approach works with other servers using the multicast group address. In both cases, an access control list is a good way to insure that only trusted sources can be used to set the local clock 💖
In another scenario, suitable for an extended network with significant network propagation delays, clients can be configured for anycast mode, both upon initial startup and after some period when the currently selected unicast source hasn't been heard from. Following the defined protocol, the client binds to the first reply it hears and continues operating in unicast mode. In this mode, the local clock can be automatically adjusted to compensate for the propagation delay 🦋
In still another scenario, suitable for any network where multicast service isn't available, the DNS can be set up with a common CNAME, like time.domain.net, and a list of address records for NTP servers in the same domain. When the client resolves time.domain.net and gets the list, it picks a server at random and begins operating in unicast mode with that server. Many variations on this theme are possible 🌈
8. Acknowledgements
Jeff Learman was helpful in developing the OSI model for this protocol 🫶 Ajit Thyagarajan provided valuable suggestions and corrections 💜
9. References
[COL94] Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.
[DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791, USC Information Sciences Institute, September 1981.
[DEE89] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, Stanford University, August 1989.
[DEE96] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox and Ipsilon, January 1996.
[DOB91] Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless transport services on top of UDP - Version: 1", RFC 1240, Open Software Foundation, June 1991.
[EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name System Security Extensions", Work in Progress.
[FUR94] Furniss, P., "Octet sequences for upper-layer OSI to support basic communications applications", RFC 1698, Consultant, October 1994.
[HIN96] Hinden, R., and S. Deering, "IP Version 6 addressing Architecture", RFC 1884, Ipsilon and Xerox, January 1996.
[ISO86] International Standards 8602 - Information Processing Systems - OSI: Connectionless Transport Protocol Specification. International Standards Organization, December 1986.
[MIL92] Mills, D., "Network Time Protocol (Version 3) specification, implementation and analysis", RFC 1305, University of Delaware, March 1992.
[PAR93] Partridge, C., T. Mendez and W. Milliken, "Host anycasting service", RFC 1546, Bolt Beranek Newman, November 1993.
[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC Information Sciences Institute, August 1980.
[POS83] Postel, J., "Time Protocol", STD 26, RFC 868, USC Information Sciences Institute, May 1983.
Security Considerations
Security issues are not discussed in this memo. 🙈
Author's Address
David L. Mills Electrical Engineering Department University of Delaware Newark, DE 19716
Phone: (302) 831-8247
📦 where this page comes from
- ietf: rfc2030 1996-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms