From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4330.txt | 1515 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1515 insertions(+) create mode 100644 doc/rfc/rfc4330.txt (limited to 'doc/rfc/rfc4330.txt') diff --git a/doc/rfc/rfc4330.txt b/doc/rfc/rfc4330.txt new file mode 100644 index 0000000..6d93a8e --- /dev/null +++ b/doc/rfc/rfc4330.txt @@ -0,0 +1,1515 @@ + + + + + + +Network Working Group D. Mills +Request for Comments: 4330 University of Delaware +Obsoletes: 2030, 1769 January 2006 +Category: Informational + + + Simple Network Time Protocol (SNTP) Version 4 + for IPv4, IPv6 and OSI + +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 + + This memorandum describes the Simple Network Time Protocol Version 4 + (SNTPv4), which is a subset of the Network Time Protocol (NTP) used + to synchronize computer clocks in the Internet. SNTPv4 can be used + when the ultimate performance of a full NTP implementation based on + RFC 1305 is neither needed nor justified. When operating with + current and previous NTP and SNTP versions, SNTPv4 requires no + changes to the specifications or known implementations, but rather + clarifies certain design features that allow operation in a simple, + stateless remote-procedure call (RPC) mode with accuracy and + reliability expectations similar to the UDP/TIME protocol described + in RFC 868. + + This memorandum obsoletes RFC 1769, which describes SNTP Version 3 + (SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to + correct certain inconsistencies in the previous documents and to + clarify header formats and protocol operations for NTPv3 (IPv4) and + SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A + further purpose is to provide guidance for home and business client + implementations for routers and other consumer devices to protect the + server population from abuse. A working knowledge of the NTPv3 + specification, RFC 1305, is not required for an implementation of + SNTP. + + + + + + + + +Mills Informational [Page 1] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + +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 ........................................25 + +1. Introduction + + The Network Time Protocol Version 3 (NTPv3), specified in RFC 1305 + [MIL92], is widely used to synchronize computer clocks in the global + Internet. It provides comprehensive mechanisms to access national + time and frequency dissemination services, organize the NTP subnet of + servers and clients, and adjust the system clock in each participant. + In most places of the Internet of today, NTP provides accuracies of + 1-50 ms, depending on the characteristics of the synchronization + source and network paths. + + RFC 1305 specifies the NTP protocol machine in terms of events, + states, transition functions and actions, and engineered algorithms + to improve the timekeeping quality and to mitigate several + synchronization sources, some of which may be faulty. To achieve + accuracies in the low milliseconds over paths spanning major portions + of the Internet, these intricate algorithms, or their functional + equivalents, are necessary. In many applications, accuracies on the + order of significant fractions of a second are acceptable. In simple + home router applications, accuracies of up to a minute may suffice. + In such cases, simpler protocols, such as the Time Protocol specified + in RFC 868 [POS83], have been used for this purpose. These protocols + involve an RPC exchange where the client requests the time of day and + the server returns it in seconds past a known reference epoch. + + NTP is designed for use by clients and servers with a wide range of + capabilities and over a wide range of network jitter and clock + frequency wander characteristics. Many users of NTP in the Internet + of today use a software distribution available from www.ntp.org. The + distribution, which includes the full suite of NTP options, + + + +Mills Informational [Page 2] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + mitigation algorithms, and security schemes, is a relatively complex, + real-time application. Although the software has been ported to a + wide variety of hardware platforms ranging from personal computers to + supercomputers, its sheer size and complexity is not appropriate for + many applications. Accordingly, it is useful to explore alternative + strategies using simpler software appropriate for less stringent + accuracy expectations. + + This memo describes the Simple Network Time Protocol Version 4 + (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, and, in fact, + it should be easy to adapt a UDP/TIME client implementation, say for + a personal computer, to operate using SNTP. Moreover, SNTP is also + designed to operate in a dedicated server configuration including an + integrated radio clock. With careful design and control of the + various latencies in the system, which is practical in a dedicated + design, it is possible to deliver time accurate on the order of + microseconds. + + The only significant protocol change in SNTPv4 from previous SNTP + versions is a modified header interpretation to accommodate Internet + Protocol Version 6 (IPv6) (RFC 2460) and OSI (RFC 1629) addressing. + However, SNTPv4 includes certain optional extensions to the basic NTP + Version 3 (NTPv3) model, including a manycast mode and a public-key- + based authentication scheme designed specifically for broadcast and + manycast applications. Although the manycast mode is described in + this memo, the authentication scheme is described in another RFC to + be submitted later. Until such time that a definitive NTPv4 + specification is published, the manycast and authentication features + should be considered provisional. In addition, this memo introduces + the kiss-o'-death message, which can be used by servers to suppress + client requests as circumstances require. + + When operating with current and previous versions of NTP and SNTP, + SNTPv4 requires no changes to the protocol or implementations now + running or likely to be implemented specifically for future NTP or + SNTP versions. The NTP and SNTP packet formats are the same, and the + arithmetic operations to calculate the client time, clock offset, and + roundtrip delay are the same. To an NTP or SNTP server, NTP and SNTP + clients are indistinguishable; to an NTP or SNTP client, NTP and SNTP + servers are indistinguishable. Like NTP servers operating in non- + symmetric modes, SNTP servers are stateless and can support large + numbers of clients; however, unlike most NTP clients, SNTP clients + normally operate with only a single server at a time. + + The full degree of reliability ordinarily expected of NTP servers is + possible only using redundant sources, diverse paths, and the crafted + + + +Mills Informational [Page 3] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + 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 operate only at the + leaves (highest stratum) of the subnet and in configurations where no + NTP or SNTP client is dependent 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 + other source of synchronization other than a reliable radio clock or + telephone modem is available. + + An important provision in this memo is the interpretation of certain + NTP header fields that 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 used primarily to detect and avoid synchronization loops. + In all NTP and SNTP versions providing IPv4 addressing, primary + servers use a four-character ASCII reference clock identifier in this + field, whereas secondary servers use the 32-bit IPv4 address of the + synchronization source. In SNTPv4 providing IPv6 and OSI addressing, + primary servers use the 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. A further use of this field is when the + server sends a kiss-o'-death message, documented later in this memo. + + NTP Version 4 (NTPv4), now in deployment, but not yet the subject + of a standards document, uses the same Reference Identifier field + as SNTPv4. + + In the case of OSI, the Connectionless Transport Service (CLTS) is + used as in [ISO86]. Each SNTP packet is transmitted as the TS- + Userdata parameter of a T-UNITDATA Request primitive. Alternately, + the header can be encapsulated in a Transport Protocol Data Unit + (TPDU), which itself is transported using UDP, as described in RFC + 1240 [DOB91]. It is not advised that NTP be operated at the upper + layers of the OSI stack, such as might be inferred from RFC 1698 + [FUR94], as this could seriously degrade accuracy. With the header + formats defined in this memo, it is in principle possible to + interwork between servers and clients of one protocol family and + another, although the practical difficulties may make this + 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 as follows. Section 2 describes 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 + + + +Mills Informational [Page 4] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + 4 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, newly minted with functions similar to the + ICMP Source Quench and ICMP Destination Unreachable messages. + Section 9 summarizes design issues important for good network + citizenry and presents an example algorithm designed to give good + reliability while minimizing network and server resource demands. + +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 + + Unless excepted in context, a reference to broadcast address means + IPv4 broadcast address, IPv4 multicast group address, or IPv6 address + of appropriate scope. Further information on the broadcast/multicast + model is in RFC 1112 [DEE89]. Details of address format, scoping + rules, etc., are beyond the scope of this memo. SNTPv4 can operate + with either unicast (point to point), broadcast (point to + multipoint), or manycast (multipoint to point) addressing modes. A + unicast client sends a request to a designated server at its unicast + address and expects a reply from which it can determine 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. A broadcast client listens on + this address and ordinarily sends no requests. + + Manycast is an extension of the anycast paradigm described in RFC + 1546 [PAR93]. It is designed for use with a set of cooperating + servers whose addresses are not known beforehand. The manycast + client sends an ordinary NTP client request to a designated broadcast + address. One or more manycast servers listen on that address. Upon + receiving a request, a manycast server sends an ordinary NTP server + reply to the client. The client then mobilizes an association for + each server found and continues operation with all of them. + Subsequently, the NTP mitigation algorithms operate to cast out all + 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 + + + + +Mills Informational [Page 5] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + 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 are assigned following the usual + IPv4, IPv6 or OSI conventions. For NTP multicast, the IANA has + reserved the IPv4 group address 224.0.1.1 and the IPv6 address ending + :101 with appropriate scope. The NTP broadcast address for OSI has + yet to be determined. Notwithstanding the IANA reserved addresses, + other multicast addresses can be used that do not conflict with + others assigned in scope. The scoping, routing, and group membership + procedures are determined by considerations 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. + + 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. In conformance with standard + Internet practice, NTP data are specified as integer or fixed-point + quantities, with bits numbered in big-endian fashion from 0 starting + at the left or most significant end. Unless specified otherwise, all + quantities are unsigned and may occupy the full field width with an + implied 0 preceding bit 0. + + + + +Mills Informational [Page 6] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + Because 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 in the + last 32 bits. In the fraction part, the non-significant low-order + bits are not specified and are ordinarily 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 allows convenient multiple-precision arithmetic and + conversion to UDP/TIME message (seconds), but does complicate the + conversion to ICMP Timestamp message (milliseconds) and Unix time + values (seconds and microseconds or seconds and nanoseconds). The + maximum number that can be represented is 4,294,967,295 seconds with + a precision of about 232 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). + There will exist a 232-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 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 + + + +Mills Informational [Page 7] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + 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 + + Both NTP and SNTP are clients of the User Datagram Protocol (UDP) + specified in RFC 768 [POS80]. The structures of the IP and UDP + headers are described in the cited specification documents and will + not be detailed further here. The UDP port number assigned by the + IANA to NTP is 123. The SNTP client should use this value in the UDP + Destination Port field for client request messages. The Source Port + field of these messages can be any nonzero value chosen for + identification or multiplexing purposes. The server interchanges + these fields for the corresponding reply messages. + + This differs from the RFC 2030 specifications, which required both + the source and destination ports to be 123. The intent of this + change is to allow the identification of particular client + implementations (which are now allowed to use unreserved port + numbers, including ones of their choosing) and to attain + compatibility with Network Address Port Translation (NAPT) + described in RFC 2663 [SRI99] and RFC 3022 [SRI01]. + + Figure 1 is a description of the NTP and SNTP message format, which + follows the IP and UDP headers in the message. This format is + identical to the NTP message format described in RFC 1305, with the + exception of the Reference Identifier field described below. For + SNTP client messages, most of these fields are zero or initialized + with pre-specified data. For completeness, the function of each + field is briefly summarized below. + + + + + + + + + + + + +Mills Informational [Page 8] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + 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 Header + + Leap Indicator (LI): This is a two-bit code warning of an impending + leap second to be inserted/deleted in the last minute of the current + day. This field is significant only in server messages, where the + values are defined as follows: + + + + + + + + + +Mills Informational [Page 9] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + 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), and + set this field to some other value when synchronized to the primary + reference clock. Once set to a value other than 3, the field is + never set to that value again, even if all synchronization sources + become unreachable or defective. + + Version Number (VN): This is a three-bit integer indicating the + NTP/SNTP version number, currently 4. If necessary to distinguish + between IPv4, IPv6, and OSI, the encapsulating context must be + inspected. + + Mode: This is a three-bit number indicating the protocol mode. The + values are defined as follows: + + 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 use + + In unicast and manycast modes, the client sets this field to 3 + (client) in the request, and the server sets it to 4 (server) in the + reply. In broadcast mode, the server sets this field to 5 + (broadcast). The other modes are not used by SNTP servers and + clients. + + Stratum: This is an eight-bit unsigned integer indicating the + stratum. This field is significant only in SNTP server messages, + where the values are defined as follows: + + 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 reserved + + + +Mills Informational [Page 10] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + Poll Interval: This is an eight-bit unsigned integer used as an + exponent of two, where the resulting value is the maximum interval + between successive messages in seconds. This field is significant + only 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 used as an exponent of + two, where the resulting value is the precision of the system clock + in seconds. This field is significant only in server messages, where + the values 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 indicating the + total roundtrip delay to the primary reference source, in seconds + with the fraction point between bits 15 and 16. Note that this + variable can take on both positive and negative values, depending on + the relative time and frequency offsets. This field is significant + only in server messages, where the values range from negative values + of a few milliseconds to positive values of several hundred + milliseconds. + + 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 Codes + + + + + + + +Mills Informational [Page 11] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + Root Dispersion: This is a 32-bit unsigned fixed-point number + indicating the maximum error due to the clock frequency tolerance, in + seconds with the fraction point between bits 15 and 16. This field + is significant only in server messages, where the values range from + zero to several hundred milliseconds. + + Reference Identifier: This is a 32-bit bitstring identifying the + particular reference source. This field is significant only in + server messages, where for stratum 0 (kiss-o'-death message) and 1 + (primary server), the value is a four-character ASCII string, left + justified and zero padded to 32 bits. For IPv4 secondary servers, + the value is the 32-bit IPv4 address of the synchronization source. + For IPv6 and OSI secondary servers, the value is 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 identifying the + external reference source according to Figure 2. If the external + reference is one of those listed, the associated code should be used. + Codes for sources not 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 is not available, because the addresses are + longer than 32 bits, and only a hash is available. However, a + walk-back can be accomplished using the NTP control message and + the reference identifier field described in RFC 1305. + + Reference Timestamp: This field is the time the system clock was last + set or corrected, in 64-bit timestamp format. + + Originate Timestamp: This is the time at which the request departed + the client for the server, in 64-bit timestamp format. + + Receive Timestamp: This is the time at which the request arrived at + the server or the reply arrived at the client, in 64-bit timestamp + format. + + Transmit Timestamp: This is the time at which the request departed + the client or the reply departed the server, in 64-bit timestamp + format. + + Authenticator (optional): When the NTP authentication scheme is + implemented, the Key Identifier and Message Digest fields contain the + message authentication code (MAC) information defined in Appendix C + of RFC 1305. + + + + +Mills Informational [Page 12] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + +5. SNTP Client Operations + + An SNTP client can operate in unicast, broadcast, or manycast modes. + 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 and 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 + received to establish the particular server for subsequent unicast + operations. Later replies from this server (duplicates) or any other + server are ignored. Other than the selection of address in the + request, the operations of manycast and unicast clients are + identical. + + Client requests are normally sent at intervals depending on the + frequency tolerance of the client clock and the required accuracy. + However, 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 are 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. They set the VN field to any version number that + is supported by the server, selected 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 specifies the VN field of the reply. A + prudent SNTP client can specify the earliest acceptable version on + the expectation that any server of that or a later version will + respond. NTP Version 3 (RFC 1305) and Version 2 (RFC 1119) servers + accept all previous versions, including Version 1 (RFC 1059). Note + that Version 0 (RFC 959) is no longer supported by current and future + NTP and SNTP servers. + + Although 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, it is highly + recommended in unicast and manycast modes. This allows a simple + calculation to determine the propagation delay between the server and + client and to align the system clock generally within a few tens of + milliseconds relative to the server. In addition, this provides a + + + +Mills Informational [Page 13] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + simple method for verifying that the server reply is in fact a + legitimate response to the specific client request and thereby for + avoiding replays. In broadcast mode, the client has no information + 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. For this purpose, the clock need not be + synchronized. The server copies this field to 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 determines a + Destination Timestamp variable as the time of arrival according to + its clock in NTP timestamp format. The following table summarizes + 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 client + + 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 possible + only in symmetric modes, which SNTP clients are forbidden to use. + The following table summarizes the required SNTP client operations in + unicast, manycast, and broadcast modes. The recommended error checks + are shown in the Reply and Broadcast columns in the table. The + message should be considered valid only if all the fields shown + contain values in the respective ranges. Whether to believe the + message if one or more of the fields marked "ignore" contain invalid + values is at the discretion of the implementation. + + + + + + + + + + +Mills Informational [Page 14] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + 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 optional + + Although not required in a conforming SNTP client implementation, it + is wise to consider a suite of sanity checks designed to avoid + various kinds of abuse that might happen as the result of server + implementation errors or malicious attack. Following is a list of + suggested checks. + + 1. When the IP source and destination addresses are available for + the client request, they should match the interchanged addresses + in the server reply. + + 2. When the UDP source and destination ports are available for the + client request, they should match the interchanged ports in the + server reply. + + 3. The Originate Timestamp in the server reply should match the + Transmit Timestamp used in the client request. + + + +Mills Informational [Page 15] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + 4. The server reply should be discarded if any of the LI, Stratum, + or Transmit Timestamp fields is 0 or the Mode field is not 4 + (unicast) or 5 (broadcast). + + 5. 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. + +6. SNTP Server Operations + + A SNTP server operating with either an NTP or SNTP client of the same + or previous versions retains no persistent state. Because an SNTP + server ordinarily does not implement the full suite of grooming and + mitigation algorithms intended to support redundant servers and + diverse network paths, it should be operated only in conjunction with + a source of external synchronization, such as a reliable radio clock + or telephone modem. In this case it operates as a primary (stratum + 1) server. + + A SNTP server can operate with any unicast, manycast, or broadcast + address or any combination of these addresses. A unicast or manycast + server receives a request (NTP mode 3), modifies certain fields in + the NTP header, and sends a reply (NTP mode 4), possibly using the + same message buffer as the request. A manycast server listens on the + designated broadcast address, but uses its own unicast IP address in + the source address field of the reply. Other than the selection of + address in the reply, the operations of manycast and unicast servers + are identical. Broadcast messages are normally sent at intervals + from 64 s to 1024 s, depending on the expected frequency tolerance of + the client clocks and the required accuracy. + + Unicast and manycast servers copy the VN and Poll fields of the + request intact to the reply and set the Stratum field to 1. + + Note that SNTP servers normally operate as primary (stratum 1) + servers. Although operating at higher strata (up to 15) while + synchronizing to an external source such as a GPS receiver is not + forbidden, this is strongly discouraged. + + If the Mode field of the request is 3 (client), the reply is set to 4 + (server). If this field is set to 1 (symmetric active), the reply is + set to 2 (symmetric passive). This allows clients configured in + either client (NTP mode 3) or symmetric active (NTP mode 1) to + interoperate successfully, even if configured in possibly suboptimal + ways. For any other value in the Mode field, the request is + + + + +Mills Informational [Page 16] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + discarded. In broadcast (unsolicited) mode, the VN field is set to + 4, the Mode field is set to 5 (broadcast), and the Poll field set to + the nearest integer base-2 logarithm of the poll interval. + + Note that it is highly desirable that a broadcast server also + supports unicast clients. This is so a potential broadcast client + can calculate the propagation delay using a client/server exchange + prior to switching to broadcast client (listen-only) mode. By + design, a manycast server is also a unicast server. There does + not seem to be a great advantage for a server to operate as both + broadcast and manycast at the same time, although the protocol + specification does not forbid it. + + A broadcast or manycast server does not send packets if not + synchronized to a correctly operating reference source. It may or + may not respond to a client request if it is not synchronized, but + the preferred option is to respond because this allows reachability + to be determined regardless of synchronization state. If the server + has never synchronized to a reference source, the LI field is set to + 3 (unsynchronized). Once synchronized to a reference source, the LI + field is set to one of the other three values and remains 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 is 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 as follows. If + the server is unsynchronized or first 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 to the Originate Timestamp field of + the reply. It is important that this field be copied intact, as 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 field is set as in the unsynchronized case above. + The Transmit Timestamp field is set to the time of day when the + + + +Mills Informational [Page 17] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + message is sent. In broadcast messages the Receive Timestamp field + is set to zero and copied from the Transmit Timestamp field in other + messages. The following table summarizes these actions. + + 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 optional + + There is some latitude on the part of most clients to forgive invalid + timestamps, such as might occur when the server is first coming up or + during periods when the reference source is inoperative. The most + important indicator of an unhealthy server is the Stratum field, in + + + + + +Mills Informational [Page 18] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + which a value of 0 indicates an unsynchronized condition. When this + value is displayed, clients should discard the server message, + regardless of the contents of other fields. + +7. Configuration and Management + + Initial setup for SNTP servers and clients can be done using a web + client, if available, or a serial port, if not. Some folks hoped + that in-service management of NTP and SNTPv4 servers and clients + could be performed using SNMP and a suitable MIB to be published, and + this has happened in some commercial SNTP servers. But, the means + that have been used in the last two decades and probably will be used + in the next is the NTP control and monitoring protocol defined in RFC + 1305. Ordinarily, SNTP servers and clients are expected to operate + with little or no site-specific configuration, other than specifying + the client IP address, subnet mask, and gateway. + + Unicast clients must be provided with one or more designated server + names or IP addresses. If more than one server is provided, one can + be used for active operation and one of the others for backup should + the active one fail or show an error condition. It is not normally + useful to use more than one server at a time, as with millions of + SNTP-enabled devices expected in the near future, such use would + represent unnecessary drain on network and server resources. + + Broadcast servers and manycast clients must be provided with the TTL + and 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 that only those clients or + servers known to be trusted will be accepted. Multicast servers and + clients must implement the IGMP protocol and be provided with the + local broadcast or multicast group address as well. The + configuration data for cryptographic authentication is beyond the + scope of this memo. + + There are several scenarios that provide automatic server discovery + and selection for SNTP clients with no pre-specified server + configuration. For instance, a role server with CNAME such as + pool.ntp.org returns a randomized list of volunteer secondary server + addresses, and the client can select one or more as candidates. For + an IP subnet or LAN segment including 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, + provision of an access control list is a good way to ensure that only + trusted sources can be used to set the system clock. + + + + + + +Mills Informational [Page 19] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + In another scenario suitable for an extended network with significant + network propagation delays, clients can be configured for manycast + addresses, both upon initial startup and after some period when the + currently selected unicast source has not been heard. Following the + defined protocol, the client binds to the server from which the first + reply is received and continues operation in unicast mode. + +8. The Kiss-o'-Death Packet + + In the rambunctious Internet of today, it is imperative that some + means be available to tell a client to stop making requests and to go + somewhere else. A recent experience involved a large number of + home/office routers all configured to use a particular university + time server. Under some error conditions, a substantial fraction of + these routers would send packets at intervals of one second. The + resulting traffic spike was dramatic, and extreme measures were + required to diagnose the problem and to bring it under control. The + conclusion is that clients must respect the means available to + targeted servers to stop them from sending packets. + + According to the NTP specification RFC 1305, if the Stratum field in + the NTP header is 1, indicating a primary server, the Reference + Identifier field contains an ASCII string identifying the particular + reference clock type. However, in RFC 1305 nothing is said about the + Reference Identifier field if the Stratum field is 0, which is called + out as "unspecified". However, if the Stratum field is 0, the + Reference Identifier field can be used to convey messages useful for + status reporting and access control. In NTPv4 and SNTPv4, packets of + this kind are called Kiss-o'-Death (KoD) packets, and the ASCII + messages they convey are called kiss codes. The KoD packets got + their name because an early use was to tell clients to stop sending + packets that violate server access controls. + + In general, an SNTP client should stop sending to a particular server + if that server returns a reply with a Stratum field of 0, regardless + of kiss code, and an alternate server is available. If no alternate + server is available, the client should retransmit using an + exponential-backoff algorithm described in the next section. + + The kiss codes can provide useful information for an intelligent + client. These codes are encoded in four-character ASCII strings left + justified and zero filled. The strings are designed for character + displays and log files. Usually, only a few of these codes can occur + with SNTP clients, including DENY, RSTR, and RATE. Others can occur + more rarely, including INIT and STEP, when the server is in some + special temporary condition. Figure 3 shows a list of the kiss codes + currently defined. These are for informational purposes only; the + list might be modified or extended in the future. + + + +Mills Informational [Page 20] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + 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 Codes + +9. On Being a Good Network Citizen + + SNTP and its big brother NTP have been in explosive growth over the + last few years, mirroring the growth of the Internet. Just about + every Internet appliance has some kind of NTP support, including + Windows XP, Cisco routers, embedded controllers, and software systems + of all kinds. This is the first edition of the SNTP RFC where it has + become necessary to lay down rules of engagement in the form of + design criteria for SNTP client implementations. This is necessary + to educate software developers regarding the proper use of Internet + time server resources as the Internet expands and demands on time + servers increase, and to prevent the recurrence of the sort of + problem mentioned above. + +10. Best Practices + + NTP and SNTP clients can consume considerable network and server + resources if they are not good network citizens. There are now + consumer Internet commodity devices numbering in the millions that + are potential customers of public and private NTP and SNTP servers. + Recent experience strongly suggests that device designers pay + particular attention to minimizing resource impacts, especially if + large numbers of these devices are deployed. The most important + + + +Mills Informational [Page 21] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + design consideration is the interval between client requests, called + the poll interval. It is extremely important that the design use the + maximum poll interval consistent with acceptable accuracy. + + 1. A client MUST NOT under any conditions use a poll interval less + than 15 seconds. + + 2. A client SHOULD increase the poll interval using exponential + backoff as performance permits and especially if the server does + not respond within a reasonable time. + + 3. A client SHOULD use local servers whenever available to avoid + unnecessary traffic on backbone networks. + + 4. A client MUST allow the operator to configure the primary and/or + alternate server names or addresses in addition to or in place of + a firmware default IP address. + + 5. 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. + + 6. 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. + + 7. 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. + + 8. A client SHOULD support the NTP access-refusal mechanism so that + a server kiss-o'-death reply in response to a client request + causes the client to cease sending requests to that server and to + switch to an alternate, if available. + + The following algorithm can be used as a pattern for specific + implementations. It uses the following 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. + + + + + + +Mills Informational [Page 22] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + 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): + + 1. 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. + + 2. When the client is first coming up or after 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. + + + + + + + +Mills Informational [Page 23] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + 3. 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. + + 4. 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 + + + + + + + + + + + + + +Mills Informational [Page 24] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + +14. Informative References + + [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. + + [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. + + [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. + + + + + +Mills Informational [Page 25] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + + [SRI01] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, January + 2001. + +Author's Address + + David L. Mills + Electrical and Computer Engineering Department + University of Delaware + Newark, DE 19716 + + Phone: (302) 831-8247 + EMail: mills@udel.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mills Informational [Page 26] + +RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78 and at www.rfc-editor.org/copyright.html, and + except as set forth therein, the authors retain all their rights. + + 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 takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Mills Informational [Page 27] + -- cgit v1.2.3