NTP

This document specifies a transport for the client-server and symmetric modes of the Network Time Protocol (NTP) that encapsulates NTP messages in messages of the Precision Time Protocol (PTP). This transport enables hardware timestamping in network interface controllers (NICs) that can timestamp only PTP messages and delay corrections in PTP transparent clocks.

This document describes a Precision Time Protocol (PTP) Profile (IEEE Standard 1588-2019) for use in an IPv4 or IPv6 enterprise information system environment. The PTP Profile uses the End-to-End delay measurement mechanism, allowing both multicast and unicast Delay Request and Delay Response messages.

This document specifies interleaved modes for the Network Time Protocol (NTP). These new modes improve the accuracy of time synchronization by enabling the use of more accurate transmit timestamps that are available only after the transmission of NTP messages. These enhancements are intended to improve timekeeping in environments where high accuracy is critical. This document updates RFC 5905 by defining these new operational modes.

The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of registries, collectively called the NTP registries.

Some registries are correct, but some include incorrect assignments and some don't follow common practice. For the sake of completeness, this document reviews all NTP and NTS registries, and corrects the registries where necessary.

This document updates RFCs 5905, 5906, 7821, 7822, and 8573.

This document defines an extension to the Babel routing protocol that measures the round-trip time (RTT) between routers and makes it possible to prefer lower-latency links over higher-latency ones.

The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.

In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949 defines two tags for time: CBOR tag 0 (RFC 3339 time as a string) and tag 1 (POSIX time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. This document is intended as the reference document for the IANA registration of the CBOR tags defined.

The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, is the mechanism used by NTP clients to synchronize with NTP servers across the Internet. This document describes a companion application to the NTPv4 client, named "Khronos", that is used as a "watchdog" alongside NTPv4 and that provides improved security against time-shifting attacks. Khronos involves changes to the NTP client's system process only. Since it does not affect the wire protocol, the Khronos mechanism is applicable to current and future time protocols.

This document describes the structure of the control messages that were historically used with the Network Time Protocol (NTP) before the advent of more modern control and management approaches. These control messages have been used to monitor and control the NTP application running on any IP network attached computer. The information in this document was originally described in Appendix B of RFC 1305. The goal of this document is to provide an updated description of the control messages described in RFC 1305 in order to conform with the updated NTP specification documented in RFC 5905.

The publication of this document is not meant to encourage the development and deployment of these control messages. This document is only providing a current reference for these control messages given the current status of RFC 1305.

This document defines a YANG data model that can be used to configure and manage Network Time Protocol (NTP) version 4. It can also be used to configure and manage version 3. The data model includes configuration data and state data.

The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based on the receipt of unsolicited packets and therefore require the use of a well-known port as the local port. However, in the case of NTP modes where the use of a well-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks. This document formally updates RFC 5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required.

This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).

NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.

Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as "packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document.

The Network Time Protocol (NTP) is one of the oldest protocols on the Internet and has been widely used since its initial publication. This document is a collection of best practices for the general operation of NTP servers and clients on the Internet. It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905.

The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement.

This document defines a YANG data model for the configuration of devices and clocks using the Precision Time Protocol (PTP) as specified in IEEE Std 1588-2008. It also defines the retrieval of the configuration information, the data sets and the running states of PTP clocks. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in internets based on TCP or IP. In particular, it defines objects for managing networks using the Precision Time Protocol (PTP), specified in IEEE Std. 1588-2008.

This memo specifies a MIB module in a manner that is both compliant to the Structure of Management Information version 2 (SMIv2) and semantically identical to the peer SMIv1 definitions.

Clock synchronization protocols are very widely used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP). As time-sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy. This memo describes a multipath approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks, without modifying these protocols. The multipath approach can significantly contribute to clock accuracy, security, and fault tolerance. The multipath approach that is presented in this document enables backward compatibility with nodes that do not support the multipath functionality.

The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations.

The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC 5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MACs).

As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.

This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds.

The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism.

This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.

This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org. This document is not an Internet Standards Track specification; it is published for informational purposes.

The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations, and other networked equipment. As time synchronization is more and more a mission-critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to set up a monitoring system that is platform- and vendor-independent. This document provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP version 4 standardization effort. [STANDARDS-TRACK]

The NTP Server Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server location information to DHCPv6 hosts. [STANDARDS-TRACK]

This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. [STANDARDS-TRACK]

RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API. This memo provides information for the Internet community.

This RFC describes a PICS Proforma translated into an Internet acceptable form. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

This memo suggests an Experimental Protocol for the OSI and Internet communities. Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism.

This paper describes a series of experiments involving over 100,000 hosts of the Internet system and located in the U.S., Europe and the Pacific. The experiments are designed to evaluate the availability, accuracy and reliability of international standard time distribution using the DARPA/NSF Internet and the Network Time Protocol (NTP), which is specified in RFC-1119. NTP is designed specifically for use in a large, diverse internet system operating at speeds from mundane to lightwave. In NTP a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration exchange precision timestamps in order to synchronize subnet clocks to each other and national time standards via wire or radio. The experiments are designed to locate Internet hosts and gateways that provide time by one of three time distribution protocols and evaluate the accuracy of their indications. For those hosts that support NTP, the experiments determine the distribution of errors and other statistics over paths spanning major portions of the globe. Finally, the experiments evaluate the accuracy and reliability of precision timekeeping using NTP and typical Internet paths involving DARPA, NSFNET and other agency networks. The experiments demonstrate that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo does not specify a standard.

This memo describes the Network Time Protocol (NTP) designed to distribute time information in a large, diverse internet system operating at speeds from mundane to lightwave. It uses a returnable- time architecture in which a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute time information within a network via local routing algorithms and time daemons. The architectures, algorithms and protocols which have evolved to NTP over several years of implementation and refinement are described in this paper. The synchronization subnet which has been in regular operation in the Internet for the last several years is described along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo describes the Network Time Protocol in RFC-1119.