RFC 4330
Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
RFC 4330: Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI 🎀
okay bestie, this one is Simple Network Time Protocol (SNTP) Version 4, written by D. Mills at the University of Delaware in January 2006 🦋. It's an Informational doc, so it's giving "here's some useful info" and not an official Internet standard. It obsoletes RFC 2030 and RFC 1769, which means those older versions are replaced by this one ✨. Nothing here updates anything else.
Status of This Memo ⭐
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 💜
Copyright (C) The Internet Society (2006).
Abstract 🌸
okay so this memo describes SNTPv4, the Simple Network Time Protocol Version 4, which is basically a lighter version of the full Network Time Protocol (NTP) that keeps computer clocks in sync across the Internet ⏰. SNTPv4 is the move when you don't need the ultimate performance of a full NTP setup based on RFC 1305, and honestly most of us don't 😭. It works with current and previous NTP and SNTP versions without needing changes to the specs or known implementations. What it does instead is clarify some design features so it can work as a simple, stateless remote-procedure call (RPC) mode 🧚. The accuracy and reliability are similar to the UDP/TIME protocol from RFC 868, which is very iconic of it 🍓.
This memo obsoletes RFC 1769, which described SNTP Version 3 (SNTPv3), and RFC 2030, which described SNTPv4 💅. The goal is to fix some inconsistencies in the older docs and clarify header formats and protocol operations for NTPv3 (IPv4) and SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP 🫶. It also gives guidance for home and business client implementations, including routers and other consumer devices, so they don't abuse the server population 🙈. And you don't need to know the NTPv3 spec in RFC 1305 to implement SNTP, which is a huge relief 🔥.
Table of Contents 🦋
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................5
2. Operating Modes and Addressing ..................................5
3. NTP Timestamp Format ............................................6
4. Message Format ..................................................8
5. SNTP Client Operations .........................................13
6. SNTP Server Operations .........................................16
7. Configuration and Management ...................................19
8. The Kiss-o'-Death Packet .......................................20
9. On Being a Good Network Citizen ................................21
10. Best Practices ................................................21
11. Security Considerations .......................................24
12. Acknowledgements ..............................................24
13. Contributors ..................................................24
14. Informative References ........................................251. Introduction ✨
okay so the Network Time Protocol Version 3 (NTPv3), specified in RFC 1305 [MIL92], is super popular for syncing computer clocks all over the global Internet 🌈. It has all the comprehensive mechanisms you could want: accessing national time and frequency dissemination services, organizing the NTP subnet of servers and clients, and adjusting the system clock in each participant 👑. These days NTP gets accuracies of 1-50 ms in most places on the Internet, depending on the synchronization source and network paths ⭐.
RFC 1305 describes the NTP protocol machine using events, states, transition functions and actions, plus engineered algorithms that improve timekeeping quality and handle several synchronization sources, some of which might be faulty 🧠. To get accuracies in the low milliseconds over paths that cross big chunks of the Internet, you really need these intricate algorithms or their functional equivalents 😤. But honestly, lots of applications are fine with accuracies measured in significant fractions of a second 💖. For a simple home router, even accuracies of up to a minute might be enough 🍓. In those cases people have used simpler protocols like the Time Protocol in RFC 868 [POS83] 🎀. These protocols work as an RPC exchange where the client asks for the time of day and the server sends it back in seconds past a known reference epoch 🦋.
NTP is built to work with clients and servers that have a wide range of capabilities, across a wide range of network jitter and clock frequency wander characteristics 💅. A lot of people use a software distribution from www.ntp.org 🌸. That distribution has the full suite of NTP options, mitigation algorithms, and security schemes, which makes it a relatively complex, real-time application 😭. It's been ported to a huge variety of hardware, from personal computers all the way up to supercomputers, but its sheer size and complexity isn't right for many applications 💀. So it makes sense to explore other strategies with simpler software that fits less stringent accuracy expectations 🧚.
This memo describes SNTPv4, which is a simplified access paradigm for servers and clients using current and previous versions of NTP and SNTP 🦋. The access paradigm is identical to the UDP/TIME Protocol, so it's pretty easy to adapt a UDP/TIME client, say on a personal computer, to use SNTP instead 🫶. SNTP is also designed for a dedicated server configuration that includes an integrated radio clock 🔥. If you carefully design and control the various latencies in the system, which is doable in a dedicated design, you can deliver time that's accurate on the order of microseconds ✨.
The only big protocol change in SNTPv4 from previous SNTP versions is a modified header interpretation so it can accommodate Internet Protocol Version 6 (IPv6) (RFC 2460) and OSI (RFC 1629) addressing 🌈. SNTPv4 also has some optional extensions to the basic NTP Version 3 (NTPv3) model, including a manycast mode and a public-key-based authentication scheme made for broadcast and manycast applications 💜. The manycast mode is described in this memo, but the authentication scheme is described in another RFC that will be submitted later 🙈. Until a definitive NTPv4 spec is published, the manycast and authentication features should be considered provisional 🍓. And this memo introduces the kiss-o'-death message, which servers can use to suppress client requests whenever circumstances call for it 🛑.
When you're working with current and previous versions of NTP and SNTP, SNTPv4 doesn't need any changes to the protocol or to implementations that are running now or are likely to be built for future NTP or SNTP versions 👑. The NTP and SNTP packet formats are the same, and the arithmetic for calculating client time, clock offset, and roundtrip delay is the same too ⭐. To an NTP or SNTP server, NTP and SNTP clients look totally indistinguishable, and to an NTP or SNTP client, NTP and SNTP servers look indistinguishable as well 🫶. Like NTP servers in non-symmetric modes, SNTP servers are stateless and can support large numbers of clients 💖. The difference is that most NTP clients can work with several servers, but SNTP clients normally operate with only a single server at a time 🎀.
The full reliability you'd normally expect from NTP servers is only possible with redundant sources, diverse paths, and the carefully crafted algorithms of a full NTP implementation 😭. It is strongly recommended that SNTP clients be used only at the extremities of the synchronization subnet 🚫. SNTP clients should only operate 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 only operate at the root (stratum 1) of the subnet, and only when no other synchronization source is available besides a reliable radio clock or telephone modem 🦋.
An important part of this memo is how it interprets certain NTP header fields to provide for IPv6 [DEE98] and OSI [COL94] addressing 🌸. The only significant difference between the NTP and SNTPv4 header formats is the four-octet Reference Identifier field, which is mainly used to detect and avoid synchronization loops 🔁. In all NTP and SNTP versions that provide IPv4 addressing, primary servers put a four-character ASCII reference clock identifier in this field, while secondary servers put in the 32-bit IPv4 address of the synchronization source 💅. In SNTPv4 with IPv6 and OSI addressing, primary servers use that same clock identifier, but secondary servers use the first 32 bits of the MD5 hash of the IPv6 or NSAP address of the synchronization source 🌈. The field has one more job too: when the server sends a kiss-o'-death message, which we'll get into later in this memo 🙈.
NTP Version 4 (NTPv4), which is in deployment now but isn't yet the subject of a standards document, uses the same Reference Identifier field as SNTPv4 ✨.
For OSI, the Connectionless Transport Service (CLTS) is used as described in [ISO86] 🫧. Each SNTP packet is sent as the TS-Userdata parameter of a T-UNITDATA Request primitive 💜. Or, the header can be wrapped in a Transport Protocol Data Unit (TPDU), which then gets carried over UDP, as described in RFC 1240 [DOB91] 🦋. It's not advised to run NTP at the upper layers of the OSI stack, like the ones RFC 1698 [FUR94] might seem to suggest, because that could seriously degrade accuracy 😬. With the header formats in this memo, it's in principle possible to interwork between servers and clients of one protocol family and another, though the practical difficulties might make that inadvisable 🍓.
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 🎀.
This memo is organized like this 🗺️. Section 2 covers how the protocol works, the various modes, and how IP addresses and UDP ports are used 🌸. Section 3 describes the NTP timestamp format, and Section 4 covers the NTP message format 🫶. Section 5 summarizes SNTP client operations, and Section 6 summarizes SNTP server operations 💖. Section 7 summarizes operation and management issues 🧚. Section 8 describes the kiss-o'-death message, which is newly minted and has functions similar to the ICMP Source Quench and ICMP Destination Unreachable messages 💀. Section 9 summarizes design issues that matter for being a good network citizen, and it presents an example algorithm designed to give good reliability while keeping network and server resource demands low 👑.
1.1. Specification of Requirements 📜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BRA97] 💅.
2. Operating Modes and Addressing ✨
okay so first things first, "broadcast address" doesn't just mean one thing here 🫶 unless the context says otherwise, it can mean an IPv4 broadcast address, an IPv4 multicast group address, or an IPv6 address of appropriate scope. if you want the whole broadcast/multicast model, check out RFC 1112 [DEE89]. the details of address format, scoping rules, and so on are out of scope for this memo, so don't look for them here 💅
SNTPv4 can run in three addressing modes: unicast (point to point), broadcast (point to multipoint), or manycast (multipoint to point) 🦋 in unicast, a 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 clock offset relative to the server. a broadcast server periodically sends an unsolicited message to a designated broadcast address, and a broadcast client listens on that address and usually doesn't send any requests at all 🎀
manycast is an extension of the anycast idea described in RFC 1546 [PAR93] 🌸 it's made for a bunch of cooperating servers whose addresses aren't known ahead of time. the manycast client sends an ordinary NTP client request to a designated broadcast address, and one or more manycast servers listening on that address pick it up. when a manycast server gets the request, it sends an ordinary NTP server reply back to the client. then the client mobilizes an association for each server it found and keeps going with all of them. after that, the NTP mitigation algorithms kick in and cast out everyone except the best three 👑
Broadcast servers should respond to client unicast requests, as well as send unsolicited broadcast messages. Broadcast clients may send unicast requests in order to measure the network propagation delay between the server and client and then continue operation in listen-only mode. However, broadcast servers may choose not to respond to unicast requests, so unicast clients should be prepared to abandon the measurement and assume a default value for the delay.
the client and server addresses get assigned using the usual IPv4, IPv6, or OSI conventions 💖 for NTP multicast, IANA has reserved the IPv4 group address 224.0.1.1 and the IPv6 address ending :101, both with appropriate scope. the NTP broadcast address for OSI hasn't been decided yet 🌈 even though IANA reserved those addresses, other multicast addresses can be used as long as they don't clash with others assigned in scope. the scoping, routing, and group membership procedures are decided by considerations that are beyond the scope of this memo ✨
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 manycast servers in scope will reply to a client request. The engineering principles that determine the proper values to be used are beyond the scope of this memo.
In the case of SNTP as specified herein, there is a very real vulnerability that SNTP broadcast clients can be disrupted by misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the Internet. It is strongly recommended that access controls and/or cryptographic authentication means be provided for additional security in such cases. 🚨💀 bestie, this one is serious, so please don't skip it!
It is intended that IP broadcast addresses will be used primarily in IP subnets and LAN segments including a fully functional NTP server with a number of dependent SNTP broadcast clients on the same subnet, and that IP multicast group addresses will be used only in cases where the TTL is engineered specifically for each service domain. However, these uses are not integral to the SNTP specification. 🧚
3. NTP Timestamp Format 🦋
SNTP uses the standard NTP timestamp format described in RFC 1305 and previous versions of that document 🎀 following standard Internet practice, NTP data are specified as integer or fixed-point quantities, with bits numbered big-endian from 0 starting at the left or most significant end. unless specified otherwise, all quantities are unsigned and may take up the full field width, with an implied 0 preceding bit 0 💅
okay, the timestamps are honestly the main product of the whole protocol, so they get their own special format 😭 an NTP timestamp is a 64-bit unsigned fixed-point number, counted in seconds relative to 0h on 1 January 1900 ✨ the integer part lives in the first 32 bits and the fraction part lives in the last 32 bits. in the fraction part, the non-significant low-order bits aren't specified and are usually 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 to provide loop detection and replay detection (see below). It is important that the bitstring be unpredictable by an intruder. One way of doing this is to generate a random 128-bit bitstring at startup. After that, each time the system clock is read, the string consisting of the timestamp and bitstring is hashed with the MD5 algorithm, then the non-significant bits of the timestamp are copied from the result. 🙈
the NTP format makes multiple-precision arithmetic and conversion to UDP/TIME messages (seconds) easy peasy 🍓 but it does make things more complicated when converting to ICMP Timestamp messages (milliseconds) and Unix time values (seconds and microseconds or seconds and nanoseconds). the maximum number it can represent is 4,294,967,295 seconds, with a precision of about 232 picoseconds, which should be more than enough 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 the 64-bit field will overflow some time in 2036 (second 4,294,967,296) 😳 there will be a 232-picosecond interval, which we're just going to ignore, every 136 years when the 64-bit field will be 0. by convention, that's interpreted as an invalid or unavailable timestamp 🫠
As the NTP timestamp format has been in use for over 20 years, it is possible that it will be in use 32 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 a leap year, and leap seconds are not included in the reckoning. 🧠✨
The arithmetic calculations used by NTP to determine the clock offset and roundtrip delay require the client time to be within 34 years of the server time before the client is launched. As the time since the Unix base 1970 is now more than 34 years, means must be available to initialize the clock at a date closer to the present, either with a time-of-year (TOY) chip or from firmware. 🕰️💖
4. Message Format ✨
okay so bestie, both NTP and SNTP run on top of UDP, which is defined in RFC 768 [POS80] 🦋 the IP and UDP headers have their own specs, so we're not going to re-explain them here. NTP's UDP port number, assigned by IANA, is 123 🎀 the SNTP client should put 123 in the UDP Destination Port field of its request messages. The Source Port can be any nonzero value the client picks for identification or multiplexing 💅 and the server swaps those two fields for its reply.
This is different from RFC 2030, which required both the source and destination ports to be 123 🙈 The reason for the change is so particular client implementations can be identified (they're now allowed to use unreserved port numbers, even ones they choose themselves) and so things stay compatible with Network Address Port Translation (NAPT), described in RFC 2663 [SRI99] and RFC 3022 [SRI01] 🌸
Figure 1 shows the NTP and SNTP message format, which sits right after the IP and UDP headers 🧚 it's basically identical to the NTP message format in RFC 1305, except for the Reference Identifier field, which we'll get to. For SNTP client messages, most of these fields are zero or already filled with pre-specified data. Still, for completeness, here's what each field does, briefly 💖
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. NTP Packet HeaderLeap Indicator (LI) 🌈 this is a two-bit code that warns about an impending leap second being added or removed in the last minute of the current day ⭐ it only matters in server messages, and the values work like this:
LI Meaning
---------------------------------------------
0 no warning
1 last minute has 61 seconds
2 last minute has 59 seconds
3 alarm condition (clock not synchronized)On startup, servers set this field to 3 (clock not synchronized) 🥺 then they switch it to some other value once they're synced to the primary reference clock. Once it's been set to something other than 3, it never goes back to 3 again, even if every synchronization source becomes unreachable or defective. iconic commitment 👑
Version Number (VN) 💜 this is a three-bit integer for the NTP/SNTP version number, which is currently 4 ✨ if you ever need to tell apart IPv4, IPv6, and OSI, you have to look at the encapsulating context.
Mode 🦋 this is a three-bit number for the protocol mode. The values go like this:
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 manycast modes, the client sets this to 3 (client) in the request, and the server sets it to 4 (server) in the reply 🫶 in broadcast mode, the server sets it to 5 (broadcast). The other modes aren't used by SNTP servers and clients, so no drama there 💅
Stratum 🌸 this is an eight-bit unsigned integer that tells you the stratum. It only matters in SNTP server messages, where the values are:
Stratum Meaning
----------------------------------------------
0 kiss-o'-death message (see below)
1 primary reference (e.g., synchronized by radio clock)
2-15 secondary reference (synchronized by NTP or SNTP)
16-255 reservedPoll Interval ⏰ this is an eight-bit unsigned integer used as an exponent of two, and the result is the maximum interval between successive messages in seconds 🍓 again, it's only significant in SNTP server messages, where the values range from 4 (16 s) to 17 (131,072 s -- about 36 h).
Precision 🎀 this is an eight-bit signed integer, also used as an exponent of two, and the result is the precision of the system clock in seconds ✨ it's only significant in server messages, where the values run from -6 for mains-frequency clocks down 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 🤓 note that this one can be positive or negative, depending on the relative time and frequency offsets, so it's not a "just positive" situation 🙃 it's only significant in server messages, where the values range from a few milliseconds below zero up to several hundred milliseconds above it.
For Reference Identifier, the codes for external reference sources are listed below. You'll want to know these by heart, honestly 🧠
Code External Reference Source
------------------------------------------------------------------
LOCL uncalibrated local clock
CESM calibrated Cesium clock
RBDM calibrated Rubidium clock
PPS calibrated quartz clock or other pulse-per-second
source
IRIG Inter-Range Instrumentation Group
ACTS NIST telephone modem service
USNO USNO telephone modem service
PTB PTB (Germany) telephone 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 Kauai 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
Figure 2. Reference Identifier CodesRoot Dispersion 🌷 this is a 32-bit unsigned fixed-point number for the maximum error caused by the clock frequency tolerance, in seconds, with the fraction point between bits 15 and 16 💫 it's only significant in server messages, where the values go from zero up to several hundred milliseconds.
Reference Identifier 🔍 this is a 32-bit bitstring that identifies the particular reference source, and it's only significant in server messages. For stratum 0 (kiss-o'-death message) and stratum 1 (primary server), the value is a four-character ASCII string, left justified and zero padded to 32 bits. For IPv4 secondary servers, it's the 32-bit IPv4 address of the synchronization source 🦋 for IPv6 and OSI secondary servers, it's the first 32 bits of the MD5 hash of the IPv6 or NSAP address of the synchronization source.
Primary (stratum 1) servers set this field to a code from Figure 2 that identifies the external reference source. If the external reference is one of the ones listed, the associated code should be used 🎀 codes for sources that aren't listed can be contrived, as appropriate.
In previous NTP and SNTP secondary servers and clients, this field was often used to walk back the synchronization subnet to the root (primary server) for management purposes 😭 In SNTPv4 with IPv6 or OSI, this feature isn't available, because the addresses are longer than 32 bits and only a hash is available. However, a walk-back can be done using the NTP control message and the reference identifier field described in RFC 1305.
Reference Timestamp 🕰️ this is the time the system clock was last set or corrected, in 64-bit timestamp format.
Originate Timestamp 🚀 this is the time the request left the client for the server, in 64-bit timestamp format.
Receive Timestamp 📬 this is the time the request arrived at the server, or the reply arrived at the client, in 64-bit timestamp format.
Transmit Timestamp 📤 this is the time the request left the client, or the reply left the server, 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, an SNTP client can run in unicast, broadcast, or manycast mode 💅 In unicast mode, the client sends a request (NTP mode 3) to a designated unicast server and expects a reply (NTP mode 4) from that server. In broadcast client mode, it sends no request at all and just waits for a broadcast (NTP mode 5) from one or more broadcast servers 👂 In manycast mode, the client sends a request (NTP mode 3) to a designated broadcast address and expects a reply (NTP mode 4) from one or more manycast servers. The client uses the first reply it receives to lock in the particular server for later unicast operations. After that, later replies from that server (duplicates) or from any other server get ignored 🙅♀️ Apart from picking the address in the request, manycast and unicast clients work the exact same way 🤝
Client requests are normally sent at intervals that depend on the frequency tolerance of the client clock and the required accuracy. BUT, under no conditions should requests be sent at less than one minute intervals ⏰ Further discussion on this point is in Section 9 🔍
A unicast or manycast client initializes the NTP message header, sends the request to the server, and strips the time of day from the Transmit Timestamp field of the reply. For this purpose, all the NTP header fields shown above get set to 0, except the Mode, VN, and optional Transmit Timestamp fields 🧚
NTP and SNTP clients set the Mode field to 3 (client) for unicast and manycast requests. For the VN field, they pick any version number that the server supports (chosen by configuration or discovery) and that can interoperate with all previous version NTP and SNTP servers 🎀 Servers reply with the same version as the request, so the VN field of the request also decides the VN field of the reply. A prudent SNTP client can specify the earliest acceptable version, on the expectation that any server of that version or a later one will respond 🧠 NTP Version 3 (RFC 1305) and Version 2 (RFC 1119) servers accept all previous versions, including Version 1 (RFC 1059). Also, Version 0 (RFC 959) is no longer supported by current and future NTP and SNTP servers, so no more v0 era. 💀
Setting the Transmit Timestamp field in the request to the time of day according to the client clock (in NTP timestamp format) is not necessary in a conforming client implementation, but it is highly recommended in unicast and manycast modes 🫶 This allows a simple calculation to figure out the propagation delay between the server and client, and it helps align the system clock to within a few tens of milliseconds of the server ✨ It also gives a simple way to check that the server reply is a legit response to that specific client request, which helps avoid replays 🛡️ In broadcast mode, the client has no info to calculate the propagation delay or to determine the validity of the server, unless one of the NTP authentication schemes is used 🔐
To calculate the roundtrip delay d and system clock offset t relative to the server, the client sets the Transmit Timestamp field in the request to the time of day according to the client clock in NTP timestamp format. The clock does not need to be synchronized for this 🙌 The server copies this field into the Originate Timestamp in the reply, and sets the Receive Timestamp and Transmit Timestamp fields to the time of day according to the server clock in NTP timestamp format.
When the server reply is received, the client works out a Destination Timestamp variable, which is the time of arrival according to its clock in NTP timestamp format. Here's the quick summary of the four timestamps 📋
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 roundtrip delay d and system clock offset t are defined as:
d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2.Note that in general both delay and offset are signed quantities and can be less than zero. However, a delay less than zero is only possible in symmetric modes, which SNTP clients are forbidden to use 🚫 The table below summarizes the required SNTP client operations in unicast, manycast, and broadcast modes. The recommended error checks are shown in the Reply and Broadcast columns. The message should be considered valid only if all the fields shown contain values in the respective ranges ✅ Whether to believe the message when one or more of the fields marked "ignore" contain invalid values is up to the implementation 🤷♀️
Field Name Unicast/Manycast Broadcast
Request Reply
---------------------------------------------------------------
LI 0 0-3 0-3
VN 1-4 copied from 1-4
request
Mode 3 4 5
Stratum 0 0-15 0-15
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 optionalSanity checks time!! Although not required in a conforming SNTP client implementation, it is wise to consider a suite of sanity checks designed to avoid the various kinds of abuse that might happen because of server implementation errors or malicious attack 😤 Here's a list of suggested checks 📝
- When the IP source and destination addresses are available for the client request, they should match the interchanged addresses in the server reply.
- When the UDP source and destination ports are available for the client request, they should match the interchanged ports in the server reply.
- The Originate Timestamp in the server reply should match the Transmit Timestamp used in the client request.
- The server reply should be discarded if any of the LI, Stratum, or Transmit Timestamp fields is 0, or if the Mode field is not 4 (unicast) or 5 (broadcast) 🙅♀️
- A truly paranoid client can check that the Root Delay and Root Dispersion fields are each greater than or equal to 0 and less than infinity, where infinity is currently a cozy number like one second 🥹 This check avoids using a server whose synchronization source has expired for a very long time. main character paranoia, and I'm here for it 🌈👑
6. SNTP Server Operations ✨
okay so a SNTP server that's talking to NTP or SNTP clients (same version or older ones) keeps no persistent state 🫶 it just answers and forgets. 🧠 Because an SNTP server usually doesn't have the whole fancy suite of grooming and mitigation algorithms meant for redundant servers and diverse network paths, it should only be run together with an external sync source, like a reliable radio clock or a telephone modem 📡. In that setup it acts as a primary (stratum 1) server, and it's giving main character energy 👑
A SNTP server can run on any unicast, manycast, or broadcast address, or any mix of them 🦋 A unicast or manycast server gets a request (NTP mode 3), tweaks certain fields in the NTP header, and sends back a reply (NTP mode 4), and it can even reuse the same message buffer as the request ♻️ A manycast server listens on the designated broadcast address but puts its own unicast IP address in the source address field of the reply 🌸 Apart from which address shows up in the reply, manycast and unicast servers work exactly the same 💅 Broadcast messages are normally sent every 64 s to 1024 s, depending on how much frequency tolerance the client clocks are expected to have and how accurate things need to be ⏰
Unicast and manycast servers copy the VN and Poll fields of the request intact into the reply and set the Stratum field to 1 💖
Note that SNTP servers normally operate as primary (stratum 1) servers. Operating at higher strata (up to 15) while syncing to an external source such as a GPS receiver isn't forbidden, but it's strongly discouraged 🙈
If the Mode field of the request is 3 (client), the reply gets set to 4 (server) 🎀 If this field is 1 (symmetric active), the reply gets set to 2 (symmetric passive) 🦋 This lets clients configured as either client (NTP mode 3) or symmetric active (NTP mode 1) interoperate successfully, even if they were set up in kinda suboptimal ways 🫠 For any other Mode value, the request is discarded 🗑️ In broadcast (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 for a broadcast server to also support unicast clients 🥺 This way a potential broadcast client can calculate the propagation delay using a client/server exchange before switching over to broadcast client (listen-only) mode. By design, a manycast server is also a unicast server 💜 There doesn't seem to be a great advantage to a server running as both broadcast and manycast at the same time, though the protocol spec doesn't forbid it 🤷♀️
A broadcast or manycast server doesn't send packets if it isn't synchronized to a correctly operating reference source 🚫 It may or may not respond to a client request while unsynchronized, but the preferred move is to respond, because that lets reachability be determined no matter the sync state 🔍 If the server has never synchronized to a reference source, the LI field is set to 3 (unsynchronized) 🥀 Once it has synced, the LI field is set to one of the other three values and stays at the last value set, even if the reference source becomes unreachable or turns faulty 🫶
If the server is synchronized to a reference source, the Stratum field is set to 1 and the Reference Identifier field is set to the ASCII source identifier shown in Figure 2 🔥 If the server is not synchronized, the Stratum field is set to zero and the Reference Identifier field is set to an ASCII error identifier (described below) 💀
The Precision field is set to reflect the maximum reading error of the system clock 🕰️ For all practical cases, it's computed as the negative base-2 logarithm 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 ✨
The timestamp fields in the server message are set like this 💅 If the server is unsynchronized or just coming up, all timestamp fields are set to zero, with one exception. If the message is a reply to a previously received client request, the Transmit Timestamp field of the request is copied unchanged into the Originate Timestamp field of the reply 🪞 This field has to be copied intact, because an NTP or SNTP client uses it to avoid bogus messages 🚨
If the server is synchronized, the Reference Timestamp is set to the time the last update was received from the reference source ⏱️ The Originate Timestamp is set just like in the unsynchronized case above 🔁 The Transmit Timestamp is set to the time of day when the message is sent 🌅 In broadcast messages, the Receive Timestamp is set to zero, and in other messages it's copied from the Transmit Timestamp 💖 Here's the summary table, bestie 📋
Field Name Unicast/Manycast Broadcast
Request Reply
----------------------------------------------------------------
LI ignore as needed as needed
VN 1-4 copied from 4
request
Mode 3 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
source update source 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 for most clients to forgive invalid timestamps 🥹 That can happen when the server is first coming up or when the reference source is down. The most important sign of an unhealthy server is the Stratum field, where a value of 0 means unsynchronized 🚩 When that value shows up, clients should discard the server message, no matter what the other fields say 🗑️💀
7. Configuration and Management 🎀
Initial setup for SNTP servers and clients can be done with a web client if one's available, or over a serial port if not 🖥️ Some folks hoped that in-service management of NTP and SNTPv4 servers and clients could be handled with SNMP and a suitable MIB that would get published, and that's actually happened in some commercial SNTP servers 💼 But the approach that's been used for the last two decades and probably will be for the next is the NTP control and monitoring protocol defined in RFC 1305 📚 Ordinarily, SNTP servers and clients are expected to work with little or no site-specific configuration, other than specifying the client IP address, subnet mask, and gateway 🧚
Unicast clients must be given one or more designated server names or IP addresses 🌐 If you provide more than one server, one can be used for active operation and another for backup in case the active one fails or shows an error condition 🔄 Using more than one server at a time isn't normally useful, because with millions of SNTP-enabled devices expected in the near future, that would be an unnecessary drain on network and server resources 😭
Broadcast servers and manycast clients must be given the TTL and the local broadcast or multicast group address 📻 Unicast and manycast servers and broadcast clients may be configured with a list of address-mask pairs for access control, so only clients or servers known to be trusted get accepted 🔐 Multicast servers and clients must implement the IGMP protocol and also be given the local broadcast or multicast group address 🌈 The configuration data for cryptographic authentication is beyond the scope of this memo 🙈
There are a few scenarios that give SNTP clients automatic server discovery and selection with no pre-specified server configuration 🔍 For instance, a role server with a CNAME such as pool.ntp.org returns a randomized list of volunteer secondary server addresses, and the client can pick one or more as candidates 🎲 For an IP subnet or LAN segment that includes an NTP or SNTP server, SNTP clients can be configured as broadcast clients 📡 The same approach can be used with multicast servers and clients 🫶 In both cases, an access control list is a good way to make sure only trusted sources can be used to set the system clock 🔒
In another scenario, suited to an extended network with significant propagation delays, clients can be configured for manycast addresses, both at 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 server from which the first reply is received and continues operating in unicast mode 🦋✨
8. The Kiss-o'-Death Packet ✨
okay bestie, this section is about the time server equivalent of "stop texting me, I'm not replying" 💀 In today's wild Internet, there has to be a way to tell a client to chill, stop spamming requests, and go bug somebody else 🙈 A real story: a bunch of home and office routers were all set up to use one university time server. Under certain error conditions, a huge chunk of those routers started sending packets every single second. The traffic spike was absolutely unhinged, and people had to take extreme measures just to figure it out and get things under control 😭 So the big takeaway is that clients must respect the tools servers have to tell them to stop sending packets. No cap. 🫶
Okay, so the NTP spec, RFC 1305, says that if the Stratum field in the NTP header is 1 (that's a primary server 👑), the Reference Identifier field holds an ASCII string naming the specific reference clock type. But RFC 1305 says nothing about the Reference Identifier when the Stratum field is 0, which it calls "unspecified" 🤷♀️ Here's the tea: when Stratum is 0, that Reference Identifier field can carry messages for status reporting and access control. In NTPv4 and SNTPv4, these packets are called Kiss-o'-Death (KoD) packets, and the ASCII messages inside them are called kiss codes 🌸 They got their name because an early use was telling clients to stop sending packets that broke the server's access rules. Iconic naming, honestly ✨
Here's the rule for SNTP clients: if a server replies with a Stratum field of 0, the client should stop sending to that particular server, regardless of kiss code, as long as an alternate server is available 🦋 If there's no alternate server, the client should retransmit using the exponential-backoff algorithm from the next section 💅
The kiss codes are lowkey so helpful for an intelligent client 🧚 Each one is a four-character ASCII string, left justified and zero filled, made to look good on character displays and in log files 🍓 Usually only a few show up with SNTP clients, mainly DENY, RSTR, and RATE. Others pop up more rarely, like INIT and STEP, when the server is in some special temporary situation 🌈 Figure 3 lists the kiss codes that are defined so far. These are for informational purposes only, and the list might get changed or extended later, so don't build your whole life around it 💖
Code Meaning
--------------------------------------------------------------
ACST The association belongs to a anycast server
AUTH Server authentication failed
AUTO Autokey sequence failed
BCST The association belongs to a broadcast server
CRYP Cryptographic authentication or identification failed
DENY Access denied by remote server
DROP Lost peer in symmetric mode
RSTR Access denied due to local policy
INIT The association has not yet synchronized for the first
time
MCST The association belongs to a manycast server
NKEY No key found. Either the key was never installed or
is not trusted
RATE Rate exceeded. The server has temporarily denied access
because the client exceeded the rate threshold
RMOT Somebody is tinkering with the association from a remote
host running ntpdc. Not to worry unless some rascal has
stolen your keys
STEP A step change in system time has occurred, but the
association has not yet resynchronized
Figure 3. Kiss Codes9. On Being a Good Network Citizen 🎀
SNTP and its big sibling NTP have been blowing up over the last few years, basically matching how the Internet itself grew 📈 Just about every Internet appliance has some kind of NTP support, from Windows XP to Cisco routers to embedded controllers to software of every flavor 💜 This is the first edition of the SNTP RFC where it became necessary to set down rules of engagement, in the form of design criteria for SNTP client implementations 🫶 It's needed to teach software developers how to use Internet time server resources properly, since the Internet keeps expanding and demand on time servers keeps climbing, and to stop the kind of mess we talked about above from happening again 😭
10. Best Practices 💅
NTP and SNTP clients can eat up a lot of network and server resources if they aren't good network citizens 💀 There are millions of consumer Internet devices out there that could be customers of public and private NTP and SNTP servers 🌈 Recent experience really suggests that device designers should pay close attention to minimizing resource impact, especially when huge numbers of these devices get deployed 🔥 The most important design consideration is the gap between client requests, called the poll interval. The design must use the maximum poll interval that still gives acceptable accuracy, and this is extremely important 👑
- A client MUST NOT under any conditions use a poll interval less than 15 seconds. 🙈
- A client SHOULD increase the poll interval using exponential backoff as performance permits, especially if the server doesn't respond within a reasonable time 🦋
- A client SHOULD use local servers whenever they're available, so there's less unnecessary traffic on backbone networks 🍓
- A client MUST allow the operator to configure the primary and/or alternate server names or addresses, either in addition to or in place of a firmware default IP address ✨
- If a firmware default server IP address is provided, it MUST be a server operated by the manufacturer or seller of the device or another server, but only with the operator's permission. 🫶
- A client SHOULD use the Domain Name System (DNS) to resolve the server IP addresses, so the operator can do effective load balancing among a server clique and change IP address binding to canonical names 🧚
- A client SHOULD re-resolve the server IP address at periodic intervals, but not at intervals less than the time-to-live field in the DNS response ⭐
- A client SHOULD support the NTP access-refusal mechanism, so that a server kiss-o'-death reply to a client request makes the client stop sending requests to that server and switch to an alternate, if one is available 💖
The following algorithm can be used as a pattern for specific implementations. It uses these variables:
Timer: This is a counter that decrements at a fixed rate. When it reaches zero, a packet is sent, and the timer is initialized with the timeout for the next packet. ⏰
Maximum timeout: This is the maximum timeout determined from the given oscillator frequency tolerance and the required accuracy. 🎯
Server Name: This is the DNS name of the server. There may be more than one of them, to be selected by some algorithm not considered here. 🌸
Server IP Address: This is the IPv4, IPv6, or OSI address of the server. 🌐
If the firmware or documentation includes specific server names, the names should be those the manufacturer or seller operates as a customer convenience, or those for which specific permission has been obtained from the operator. A DNS request for a generic server name, such as ntp.mytimeserver.com, should result in a random selection of server IP addresses available for that purpose. Each time a DNS request is received, a new randomized list is returned. The client ordinarily uses the first address on the list. 🎲
When candidate SNTP or NTP servers are selected, it is imperative to respect the server operator's conditions of access. Lists of public servers and their conditions of access are available at www.ntp.org. A semi-automatic server discovery scheme using DNS is described at that site. Some ISPs operate public servers, although finding them via their help desks can be difficult. 🙈
A well-behaved client operates as follows (note that steps 2-4 constitute a synchronization loop): 🧚
- Consider the specified frequency tolerance of the system clock oscillator. Define the required accuracy of the system clock, then calculate the maximum timeout. For instance, if the frequency tolerance is 200 parts per million (PPM) and the required accuracy is one minute, the maximum timeout is about 3.5 days. Use the longest maximum timeout possible given the system constraints to minimize time server aggregate load, but never make it less than 15 minutes. 🌈
- When the client is first coming up or after a reset, randomize the timeout from one to five minutes. This is to minimize shock when 3000 PCs are rebooted at the same time power is restored after a blackout 😭 Assume at this time that the IP address is unknown and that the system clock is unsynchronized. Otherwise, use the timeout value as calculated in previous loop steps. Note that it may be necessary to refrain from implementing the aforementioned random delay for some classes of International Computer Security Association (ICSA) certification. 🔥
- When the timer reaches zero, if the IP address is not known, send a DNS query packet; otherwise, send an NTP request packet to that address. If no reply packet has been heard since the last timeout, double the timeout, but do not make it greater than the maximum timeout. If primary and secondary time servers have been configured, alternate queries between the primary and secondary servers when no successful response has been received. 👑
- If a DNS reply packet is received, save the IP address and continue at step 2. If a KoD packet is received, remove that time server from the list, activate the secondary time server, and continue at step 2. If a received packet fails the sanity checks, drop that packet and also continue at step 2. If a valid NTP packet is received, update the system clock, set the timeout to the maximum, and continue at step 2. 💖
11. Security Considerations 🔐
Without cryptographic authentication, SNTPv4 service is vulnerable to disruption by misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the Internet. It is strongly recommended that access controls and/or cryptographic authentication means be provided for additional security. This document includes protocol provisions for adding such security mechanisms, but it does not define the mechanisms themselves. A separate document [MIL03] in preparation will define a cryptographic security mechanism for SNTP. 💀
12. Acknowledgements 🫶
Jeff Learman was helpful in developing the OSI model for this protocol. Ajit Thyagarajan provided valuable suggestions and corrections. 🌸
13. Contributors ✨
D. Plonka 🎀
J. Montgomery 🧚
14. Informative References 📚✨
Okay bestie, here's the reading list 🤓📖. These are the background RFCs and docs that the spec leans on. Every single one is listed below with all its details.
[BRA97]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑[COL94]Colella, R., Callon, R., Gardner, E., and Y. Rekhter, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1629, May 1994. 🗺️[DEE89]Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. 📡[DEE98]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 🌐[DOB91]Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless transport services on top of UDP: Version 1", RFC 1240, June 1991. 🧩[FUR94]Furniss, P., "Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications", RFC 1698, October 1994. 🎀[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, March 1992. ⏰ this is the OG time protocol, iconic 💜[MIL03]Mills, D., "The Autokey Security Architecture, Protocol and Algorithms",http://eecis.udel.edu/~mills/database/reports/stime/stime.pdf, August 2003. 🔐[PAR93]Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. 🦋[POS80]Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. 💌 the OG UDP, legendary[POS83]Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, May 1983. 🕰️[SRI99]Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. 🧭[SRI01]Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. 🔁
Author's Address 🖋️
The author is David L. Mills, and you can reach him at the address below 💌🏫.
David L. Mills
Electrical and Computer Engineering Department
University of Delaware
Newark, DE 19716
Phone: (302) 831-8247
EMail: mills@udel.eduFull Copyright Statement ©️
Copyright (C) The Internet Society (2006). 🌸
This document is covered by the rights, licenses and restrictions in BCP 78, which you can read at www.rfc-editor.org/copyright.html. Unless that text says otherwise, the authors keep all of their rights 💅.
The document and its information are handed over "AS IS". Here's the legal fine print, verbatim, because it matters 👇:
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧠🔒
The IETF doesn't take a side on whether any intellectual property rights or other rights that someone might claim over this technology are valid or how far they reach. It also doesn't say whether a license would be available. And it hasn't independently checked for any such rights either 🤷♀️. If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79 📜.
Copies of IPR disclosures sent to the IETF Secretariat, along with any assurances of licenses, are available from the IETF online IPR repository at http://www.ietf.org/ipr. The same goes for attempts to get a general license or permission for implementers or users to use the proprietary rights in this spec 🔍.
The IETF also invites anyone to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬✨.
Acknowledgement 🫶
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). Thank you, IASA, you keep the lights on 💖🌈.
📦 where this page comes from
- ietf: rfc4330 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms