draft-ietf-ntp-ntpv4-proto-08.txt   draft-ietf-ntp-ntpv4-proto-09.txt 
NTP WG J. Burbank, Ed. NTP WG J. Burbank, Ed.
Internet-Draft W. Kasch, Ed. Internet-Draft W. Kasch, Ed.
Obsoletes: RFC 4330, RFC 1305 JHU/APL Obsoletes: RFC 4330, RFC 1305 JHU/APL
(if approved) J. Martin, Ed. (if approved) J. Martin, Ed.
Intended status: Standards Track Daedelus Intended status: Standards Track Woven
Expires: May 19, 2008 D. Mills Expires: August 28, 2008 D. Mills
U. Delaware U. Delaware
November 16, 2007 February 25, 2008
Network Time Protocol Version 4 Protocol And Algorithms Specification Network Time Protocol Version 4 Protocol And Algorithms Specification
draft-ietf-ntp-ntpv4-proto-08 draft-ietf-ntp-ntpv4-proto-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 19, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Network Time Protocol (NTP) is widely used to synchronize The Network Time Protocol (NTP) is widely used to synchronize
computer clocks in the Internet. This document describes NTP Version computer clocks in the Internet. This document describes NTP Version
4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3) 4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3)
described in RFC 1305, as well as previous versions of the protocol. described in RFC 1305, as well as previous versions of the protocol.
NTPv4 includes a modified protocol header to accommodate the Internet NTPv4 includes a modified protocol header to accommodate the Internet
Protocol Version 6 address family. NTPv4 includes fundamental Protocol Version 6 address family. NTPv4 includes fundamental
improvements in the mitigation and discipline algorithms which extend improvements in the mitigation and discipline algorithms which extend
the potential accuracy to the tens of microseconds with modern the potential accuracy to the tens of microseconds with modern
workstations and fast LANs. It includes a dynamic server discovery workstations and fast LANs. It includes a dynamic server discovery
scheme, so that in many cases specific server configuration is not scheme, so that in many cases specific server configuration is not
required. It corrects certain errors in the NTPv3 design and required. It corrects certain errors in the NTPv3 design and
implementation and includes an optional extension mechanism. implementation and includes an optional extension mechanism.
Table of Contents Table of Contents
skipping to change at page 2, line 30 skipping to change at page 2, line 25
3.1. Dynamic Server Discovery . . . . . . . . . . . . . . . . 7 3.1. Dynamic Server Discovery . . . . . . . . . . . . . . . . 7
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Implementation Model . . . . . . . . . . . . . . . . . . . . 10 5. Implementation Model . . . . . . . . . . . . . . . . . . . . 10
6. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 16 7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Structure Conventions . . . . . . . . . . . . . . . . . . 16 7.1. Structure Conventions . . . . . . . . . . . . . . . . . . 16
7.2. Global Parameters . . . . . . . . . . . . . . . . . . . . 16 7.2. Global Parameters . . . . . . . . . . . . . . . . . . . . 16
7.3. Packet Header Variables . . . . . . . . . . . . . . . . . 17 7.3. Packet Header Variables . . . . . . . . . . . . . . . . . 17
7.4. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . 23 7.4. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . 23
7.5. NTP Extension Field Format . . . . . . . . . . . . . . . 25 7.5. NTP Extension Field Format . . . . . . . . . . . . . . . 25
8. On Wire Protocol . . . . . . . . . . . . . . . . . . . . . . 25 8. On Wire Protocol . . . . . . . . . . . . . . . . . . . . . . 26
9. Peer Process . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Peer Process . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Peer Process Variables . . . . . . . . . . . . . . . . . 30 9.1. Peer Process Variables . . . . . . . . . . . . . . . . . 31
9.2. Peer Process Operations . . . . . . . . . . . . . . . . . 32 9.2. Peer Process Operations . . . . . . . . . . . . . . . . . 33
10. Clock Filter Algorithm . . . . . . . . . . . . . . . . . . . 36 10. Clock Filter Algorithm . . . . . . . . . . . . . . . . . . . 37
11. System Process . . . . . . . . . . . . . . . . . . . . . . . 38 11. System Process . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. System Process Variables . . . . . . . . . . . . . . . . 38 11.1. System Process Variables . . . . . . . . . . . . . . . . 39
11.2. System Process Operations . . . . . . . . . . . . . . . . 39 11.2. System Process Operations . . . . . . . . . . . . . . . . 40
11.2.1. Selection Algorithm . . . . . . . . . . . . . . . . 42 11.2.1. Selection Algorithm . . . . . . . . . . . . . . . . 43
11.2.2. Cluster Algorithm . . . . . . . . . . . . . . . . . 43 11.2.2. Cluster Algorithm . . . . . . . . . . . . . . . . . 44
11.2.3. Combine Algorithm . . . . . . . . . . . . . . . . . 44 11.2.3. Combine Algorithm . . . . . . . . . . . . . . . . . 45
11.3. Clock Discipline Algorithm . . . . . . . . . . . . . . . 46 11.3. Clock Discipline Algorithm . . . . . . . . . . . . . . . 47
12. Clock Adjust Process . . . . . . . . . . . . . . . . . . . . 50 12. Clock Adjust Process . . . . . . . . . . . . . . . . . . . . 51
13. Poll Process . . . . . . . . . . . . . . . . . . . . . . . . 50 13. Poll Process . . . . . . . . . . . . . . . . . . . . . . . . 51
13.1. Poll Process Variables . . . . . . . . . . . . . . . . . 50 13.1. Poll Process Variables . . . . . . . . . . . . . . . . . 51
13.2. Poll Process Operations . . . . . . . . . . . . . . . . . 51 13.2. Poll Process Operations . . . . . . . . . . . . . . . . . 52
14. Simple Network Time Protocol (SNTP) . . . . . . . . . . . . . 53 14. Simple Network Time Protocol (SNTP) . . . . . . . . . . . . . 54
15. Security Considerations . . . . . . . . . . . . . . . . . . . 54 15. Security Considerations . . . . . . . . . . . . . . . . . . . 55
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
18.1. Informative References . . . . . . . . . . . . . . . . . 56 18.1. Informative References . . . . . . . . . . . . . . . . . 57
18.2. Normative References . . . . . . . . . . . . . . . . . . 57 18.2. Normative References . . . . . . . . . . . . . . . . . . 58
Appendix A. Code Skeleton . . . . . . . . . . . . . . . . . . . 57 Appendix A. Code Skeleton . . . . . . . . . . . . . . . . . . . 58
A.1. Global Definitions . . . . . . . . . . . . . . . . . . . 58 A.1. Global Definitions . . . . . . . . . . . . . . . . . . . 59
A.1.1. Definitions, Constants, Parameters . . . . . . . . . 58 A.1.1. Definitions, Constants, Parameters . . . . . . . . . 59
A.1.2. Packet Data Structures . . . . . . . . . . . . . . . 61 A.1.2. Packet Data Structures . . . . . . . . . . . . . . . 62
A.1.3. Association Data Structures . . . . . . . . . . . . 62 A.1.3. Association Data Structures . . . . . . . . . . . . 63
A.1.4. System Data Structures . . . . . . . . . . . . . . . 64 A.1.4. System Data Structures . . . . . . . . . . . . . . . 66
A.1.5. Local Clock Data Structures . . . . . . . . . . . . 65 A.1.5. Local Clock Data Structures . . . . . . . . . . . . 67
A.1.6. Function Prototypes . . . . . . . . . . . . . . . . 65 A.1.6. Function Prototypes . . . . . . . . . . . . . . . . 67
A.2. Main Program and Utility Routines . . . . . . . . . . . . 66 A.2. Main Program and Utility Routines . . . . . . . . . . . . 68
A.3. Kernel Input/Output Interface . . . . . . . . . . . . . . 69 A.3. Kernel Input/Output Interface . . . . . . . . . . . . . . 71
A.4. Kernel System Clock Interface . . . . . . . . . . . . . . 69 A.4. Kernel System Clock Interface . . . . . . . . . . . . . . 71
A.5. Peer Process . . . . . . . . . . . . . . . . . . . . . . 71 A.5. Peer Process . . . . . . . . . . . . . . . . . . . . . . 73
A.5.1. receive() . . . . . . . . . . . . . . . . . . . . . 72 A.5.1. receive() . . . . . . . . . . . . . . . . . . . . . 74
A.5.2. clock_filter() . . . . . . . . . . . . . . . . . . . 79 A.5.2. clock_filter() . . . . . . . . . . . . . . . . . . . 81
A.5.3. fast_xmit() . . . . . . . . . . . . . . . . . . . . 83 A.5.3. fast_xmit() . . . . . . . . . . . . . . . . . . . . 85
A.5.4. access() . . . . . . . . . . . . . . . . . . . . . . 85 A.5.4. access() . . . . . . . . . . . . . . . . . . . . . . 87
A.5.5. System Process . . . . . . . . . . . . . . . . . . . 85 A.5.5. System Process . . . . . . . . . . . . . . . . . . . 87
A.5.6. Clock Adjust Process . . . . . . . . . . . . . . . . 99 A.5.6. Clock Adjust Process . . . . . . . . . . . . . . . . 101
A.5.7. Poll Process . . . . . . . . . . . . . . . . . . . . 100 A.5.7. Poll Process . . . . . . . . . . . . . . . . . . . . 102
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109
Intellectual Property and Copyright Statements . . . . . . . . . 108 Intellectual Property and Copyright Statements . . . . . . . . . 110
1. Introduction 1. Introduction
This document defines the Network Time Protocol Version 4 (NTPv4), This document defines the Network Time Protocol Version 4 (NTPv4),
which is widely used to synchronize system clocks among a set of which is widely used to synchronize system clocks among a set of
distributed time servers and clients. It describes the core distributed time servers and clients. It describes the core
architecture, protocol, state machines, data structures and architecture, protocol, state machines, data structures and
algorithms. NTPv4 introduces new functionality to NTPv3, as algorithms. NTPv4 introduces new functionality to NTPv3, as
described in [1], and functionality expanded from SNTPv4 as described described in [RFC1305], and functionality expanded from SNTPv4 as
in [2] (SNTPv4 is a subset of NTPv4). This document obsoletes [1], described in [RFC4330] (SNTPv4 is a subset of NTPv4). This document
and [2]. While certain minor changes have been made in some protocol obsoletes [RFC1305], and [RFC4330]. While certain minor changes have
header fields, these do not affect the interoperability between NTPv4 been made in some protocol header fields, these do not affect the
and previous versions of NTP and SNTP. interoperability between NTPv4 and previous versions of NTP and SNTP.
The NTP subnet model includes a number of widely accessible primary The NTP subnet model includes a number of widely accessible primary
time servers synchronized by wire or radio to national standards. time servers synchronized by wire or radio to national standards.
The purpose of the NTP protocol is to convey timekeeping information The purpose of the NTP protocol is to convey timekeeping information
from these primary servers to secondary time servers and clients via from these primary servers to secondary time servers and clients via
both private networks and the public Internet. Precisely tuned both private networks and the public Internet. Precisely tuned
algorithms mitigate errors that may result from network disruptions, algorithms mitigate errors that may result from network disruptions,
server failures and possible hostile actions. Servers and clients server failures and possible hostile actions. Servers and clients
are configured such that values flow towards clients from the primary are configured such that values flow towards clients from the primary
servers at the root via branching secondary servers. servers at the root via branching secondary servers.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
structures necessary to interoperate between conforming structures necessary to interoperate between conforming
implementations. Appendix A contains additional detail in the form implementations. Appendix A contains additional detail in the form
of a skeleton program, including data structures and code segments of a skeleton program, including data structures and code segments
for the core algorithms as well as the mitigation algorithms used to for the core algorithms as well as the mitigation algorithms used to
enhance reliability and accuracy. While the skeleton program and enhance reliability and accuracy. While the skeleton program and
other descriptions in this document apply to a particular other descriptions in this document apply to a particular
implementation, they are not intended as the only way the required implementation, they are not intended as the only way the required
functions can be implemented. While the NTPv3 symmetric key functions can be implemented. While the NTPv3 symmetric key
authentication scheme described in this document has been carried authentication scheme described in this document has been carried
over from NTPv3, the Autokey public key authentication scheme new to over from NTPv3, the Autokey public key authentication scheme new to
NTPv4 is described in [3]. NTPv4 is described in [ref3].
The NTP protocol includes modes of operation described in Section 2 The NTP protocol includes modes of operation described in Section 2
using data types described in Section 6 and data structures described using data types described in Section 6 and data structures described
in Section 7. The implementation model described in Section 5 is in Section 7. The implementation model described in Section 5 is
based on a threaded, multi-process architecture, although other based on a threaded, multi-process architecture, although other
architectures could be used as well. The on-wire protocol described architectures could be used as well. The on-wire protocol described
in Section 8 is based on a returnable-time design which depends only in Section 8 is based on a returnable-time design which depends only
on measured clock offsets, but does not require reliable message on measured clock offsets, but does not require reliable message
delivery. Reliable message delivery such as TCP[11] can actually delivery. Reliable message delivery such as TCP[RFC0793] can
make the delivered NTP packet less reliable since retries would actually make the delivered NTP packet less reliable since retries
increase the delay value and other errors. The synchronization would increase the delay value and other errors. The synchronization
subnet is a self-organizing, hierarchical, master-slave network with subnet is a self-organizing, hierarchical, master-slave network with
synchronization paths determined by a shortest-path spanning tree and synchronization paths determined by a shortest-path spanning tree and
defined metric. While multiple masters (primary servers) may exist, defined metric. While multiple masters (primary servers) may exist,
there is no requirement for an election protocol. there is no requirement for an election protocol.
This document includes material from [4], which contains flow charts This document includes material from [ref9], which contains flow
and equations unsuited for RFC format. There is much additional charts and equations unsuited for RFC format. There is much
information in [5], including an extensive technical analysis and additional information in [ref7], including an extensive technical
performance assessment of the protocol and algorithms in this analysis and performance assessment of the protocol and algorithms in
document. The reference implementation is available at www.ntp.org. this document. The reference implementation is available at
www.ntp.org.
The remainder of this document contains numerous variables and The remainder of this document contains numerous variables and
mathematical expressions. Some variables take the form of Greek mathematical expressions. Some variables take the form of Greek
characters, which are spelled out by their full case-sensitive name. characters, which are spelled out by their full case-sensitive name.
For example DELTA refers to the uppercase Greek character, while For example DELTA refers to the uppercase Greek character, while
delta refers to the lowercase character. Furthermore, subscripts are delta refers to the lowercase character. Furthermore, subscripts are
denoted with '_', for example theta_i refers to the lowercase Greek denoted with '_', for example theta_i refers to the lowercase Greek
character theta with subscript i, or phonetically theta sub i. In character theta with subscript i, or phonetically theta sub i. In
this document all time values are in seconds (s), and all frequencies this document all time values are in seconds (s), and all frequencies
will be specified as fractional frequency offsets (FFO) (pure will be specified as fractional frequency offsets (FFO) (pure
number). It is often convenient to express these FFOs in parts per number). It is often convenient to express these FFOs in parts per
million (ppm). million (ppm).
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [12]. document are to be interpreted as described in [RFC2119].
2. Modes of Operation 2. Modes of Operation
An NTP implementation operates as a primary server, secondary server An NTP implementation operates as a primary server, secondary server
or client. A primary server is synchronized to a reference clock or client. A primary server is synchronized to a reference clock
directly traceable to UTC (eg, GPS, Galileo, etc). A client directly traceable to UTC (eg, GPS, Galileo, etc). A client
synchronizes to one or more upstream servers, but does not provide synchronizes to one or more upstream servers, but does not provide
synchronization to dependent clients. A secondary server has one or synchronization to dependent clients. A secondary server has one or
more upstream servers and one or more downstream servers or clients. more upstream servers and one or more downstream servers or clients.
All servers and clients who are fully NTPv4 compliant MUST implement All servers and clients who are fully NTPv4 compliant MUST implement
skipping to change at page 6, line 41 skipping to change at page 6, line 42
| Broadcast Client | 6 | N/A | | Broadcast Client | 6 | N/A |
+-------------------+--------------+-------------+ +-------------------+--------------+-------------+
Figure 1: Association and Packet Modes Figure 1: Association and Packet Modes
In the client/server variant a persistent client sends client (mode In the client/server variant a persistent client sends client (mode
3) packets to a server, which returns server (mode 4) packets. 3) packets to a server, which returns server (mode 4) packets.
Servers provide synchronization to one or more clients, but do not Servers provide synchronization to one or more clients, but do not
accept synchronization from them. A server can also be a reference accept synchronization from them. A server can also be a reference
clock driver which obtains time directly from a standard source such clock driver which obtains time directly from a standard source such
as a GPS receiver or telephone modem service. In this varient, as a GPS receiver or telephone modem service. In this variant,
clients pull synchronization from servers. clients pull synchronization from servers.
In the symmetric variant a peer operates as both a server and client In the symmetric variant a peer operates as both a server and client
using either a symmetric active or symmetric passive association. A using either a symmetric active or symmetric passive association. A
persistent symmetric active association sends symmetric active (mode persistent symmetric active association sends symmetric active (mode
1) packets to a symmetric active peer association. Alternatively, an 1) packets to a symmetric active peer association. Alternatively, an
ephemeral symmetric passive association can be mobilized upon arrival ephemeral symmetric passive association can be mobilized upon arrival
of a symmetric active packet with no matching association. That of a symmetric active packet with no matching association. That
association sends symmetric passive (mode 2) packets and persists association sends symmetric passive (mode 2) packets and persists
until error or timeout. Peers both push and pull synchronization to until error or timeout. Peers both push and pull synchronization to
skipping to change at page 8, line 34 skipping to change at page 8, line 35
population includes only the best candidates that have most recently population includes only the best candidates that have most recently
responded with an NTP packet to discipline the system clock. responded with an NTP packet to discipline the system clock.
4. Definitions 4. Definitions
A number of technical terms are defined in this section. A timescale A number of technical terms are defined in this section. A timescale
is a frame of reference where time is expressed as the value of a is a frame of reference where time is expressed as the value of a
monotonically increasing binary counter with an indefinite number of monotonically increasing binary counter with an indefinite number of
bits. It counts in seconds and fractions of a second, when a decimal bits. It counts in seconds and fractions of a second, when a decimal
point is employed. The Coordinated Universal Time (UTC) timescale is point is employed. The Coordinated Universal Time (UTC) timescale is
defined by ITU-R TF.460[6]. Under the auspices of the Metre defined by ITU-R TF.460[ITU-R_TF.460]. Under the auspices of the
Convention of 1865, in 1975 the CGPM[7] strongly endorsed the use of Metre Convention of 1865, in 1975 the CGPM[CGPM] strongly endorsed
UTC as the basis for civil time. the use of UTC as the basis for civil time.
The Coordinated Universal Time (UTC) timescale represents mean solar The Coordinated Universal Time (UTC) timescale represents mean solar
time as disseminated by national standards laboratories. The system time as disseminated by national standards laboratories. The system
time is represented by the system clock maintained by the hardware time is represented by the system clock maintained by the hardware
and operating system. The goal of the NTP algorithms is to minimize and operating system. The goal of the NTP algorithms is to minimize
both the time difference and frequency difference between UTC and the both the time difference and frequency difference between UTC and the
system clock. When these differences have been reduced below nominal system clock. When these differences have been reduced below nominal
tolerances, the system clock is said to be synchronized to UTC. tolerances, the system clock is said to be synchronized to UTC.
The date of an event is the UTC time at which the event takes place. The date of an event is the UTC time at which the event takes place.
skipping to change at page 12, line 19 skipping to change at page 12, line 19
function rather than a simple variable. In the intended design the function rather than a simple variable. In the intended design the
clock discipline process uses the adjtime() function if the clock discipline process uses the adjtime() function if the
adjustment is less than a designated threshold, and the adjustment is less than a designated threshold, and the
settimeofday() function if above the threshold. The manner in which settimeofday() function if above the threshold. The manner in which
this is done and the value of the threshold as described in this is done and the value of the threshold as described in
Section 10. Section 10.
6. Data Types 6. Data Types
All NTP time values are represented in twos-complement format, with All NTP time values are represented in twos-complement format, with
bits numbered in big-endian (as described in Appendix A of [13]) bits numbered in big-endian (as described in Appendix A of [RFC0791])
fashion from zero starting at the left, or high-order, position. fashion from zero starting at the left, or high-order, position.
There are three NTP time formats, a 128-bit date format, a 64-bit There are three NTP time formats, a 128-bit date format, a 64-bit
timestamp format and a 32-bit short format, as shown in Figure 3. timestamp format and a 32-bit short format, as shown in Figure 3.
The 128-bit date format is used where sufficient storage and word The 128-bit date format is used where sufficient storage and word
size are available. It includes a 64-bit signed seconds field size are available. It includes a 64-bit signed seconds field
spanning 584 billion years and a 64-bit fraction field resolving .05 spanning 584 billion years and a 64-bit fraction field resolving .05
attosecond (i.e., 0.5e-18). For convenience in mapping between attosecond (i.e., 0.5e-18). For convenience in mapping between
formats, the seconds field is divided into a 32-bit Era Number field formats, the seconds field is divided into a 32-bit Era Number field
and a 32-bit Era Offset field. Eras cannot be produced by NTP and a 32-bit Era Offset field. Eras cannot be produced by NTP
directly, nor is there need to do so. When necessary, they can be directly, nor is there need to do so. When necessary, they can be
skipping to change at page 17, line 50 skipping to change at page 17, line 50
7.3. Packet Header Variables 7.3. Packet Header Variables
The most important state variables from an external point of view are The most important state variables from an external point of view are
the packet header variables described in Figure 7 and below. The NTP the packet header variables described in Figure 7 and below. The NTP
packet header consists of an integral number of 32-bit (4 octet) packet header consists of an integral number of 32-bit (4 octet)
words in network byte order. The packet format consists of three words in network byte order. The packet format consists of three
components, the header itself, one or more optional extension fields components, the header itself, one or more optional extension fields
and an optional message authentication code (MAC). The header and an optional message authentication code (MAC). The header
component is identical to the NTPv3 header and previous versions. component is identical to the NTPv3 header and previous versions.
The optional extension fields are used by the Autokey public key The optional extension fields are used by the Autokey public key
cryptographic algorithms described in [3]. The optional MAC is used cryptographic algorithms described in [ref3]. The optional MAC is
by both Autokey and the symmetric key cryptographic algorithm used by both Autokey and the symmetric key cryptographic algorithm
described in this report. described in this report.
+-----------+------------+-----------------------+ +-----------+------------+-----------------------+
| Name | Formula | Description | | Name | Formula | Description |
+-----------+------------+-----------------------+ +-----------+------------+-----------------------+
| leap | leap | leap indicator (LI) | | leap | leap | leap indicator (LI) |
| version | version | version number (VN) | | version | version | version number (VN) |
| mode | mode | mode | | mode | mode | mode |
| stratum | stratum | stratum | | stratum | stratum | stratum |
| poll | poll | poll exponent | | poll | poll | poll exponent |
skipping to change at page 18, line 28 skipping to change at page 18, line 28
| org | T1 | origin timestamp | | org | T1 | origin timestamp |
| rec | T2 | receive timestamp | | rec | T2 | receive timestamp |
| xmt | T3 | transmit timestamp | | xmt | T3 | transmit timestamp |
| dst | T4 | destination timestamp | | dst | T4 | destination timestamp |
| keyid | keyid | key ID | | keyid | keyid | key ID |
| MAC | MAC | message digest | | MAC | MAC | message digest |
+-----------+------------+-----------------------+ +-----------+------------+-----------------------+
Figure 7: Packet Header Variables Figure 7: Packet Header Variables
The NTP packet is a UDP datagram[14]. Some fields use multiple words The NTP packet is a UDP datagram[RFC0768]. Some fields use multiple
and others are packed in smaller fields within a word. The NTP words and others are packed in smaller fields within a word. The NTP
packet header shown in Figure 8 has 12 words followed by optional packet header shown in Figure 8 has 12 words followed by optional
extension fields and finally an optional message authentication code extension fields and finally an optional message authentication code
(MAC) consisting of the key identifier field and message digest (MAC) consisting of the key identifier field and message digest
field. field.
0 1 2 3 0 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 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 | |LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 5 skipping to change at page 20, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier | | Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MAC (128) | | MAC (128) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Packet Header Format Figure 8: Packet Header Format
The extension fields are used to add optional capabilities, for The extension fields are used to add optional capabilities, for
example, the Autokey security protocol [3]. The extension field example, the Autokey security protocol [ref3]. The extension field
format is presented in order that the packet can be parsed without format is presented in order that the packet can be parsed without
knowledge of the extension field functions. The MAC is used by both knowledge of the extension field functions. The MAC is used by both
Autokey and the symmetric key authentication scheme described in Autokey and the symmetric key authentication scheme described in
Appendix A. Appendix A.
A list of the packet header variables is shown in Figure 7 and A list of the packet header variables is shown in Figure 7 and
described in detail below. Except for a minor variation when using described in detail below. Except for a minor variation when using
the IPv6 address family, these fields are backwards compatible with the IPv6 address family, these fields are backwards compatible with
NTPv3. The packet header fields apply to both transmitted packets (x NTPv3. The packet header fields apply to both transmitted packets (x
prefix) and received packets (r prefix). In Figure 8 the size of prefix) and received packets (r prefix). In Figure 8 the size of
skipping to change at page 22, line 12 skipping to change at page 22, line 12
Root Delay (rootdelay): Total round trip delay to the reference Root Delay (rootdelay): Total round trip delay to the reference
clock, in NTP short format. clock, in NTP short format.
Root Dispersion (rootdisp): Total dispersion to the reference clock, Root Dispersion (rootdisp): Total dispersion to the reference clock,
in NTP short format. in NTP short format.
Reference ID (refid): 32-bit code identifying the particular server Reference ID (refid): 32-bit code identifying the particular server
or reference clock. The interpretation depends on the value in the or reference clock. The interpretation depends on the value in the
stratum field. For packet stratum 0 (unspecified or invalid) this is stratum field. For packet stratum 0 (unspecified or invalid) this is
a four-character ASCII[15] string, called the kiss code, used for a four-character ASCII[RFC1345] string, called the kiss code, used
debugging and monitoring purposes. For stratum 1 (reference clock) for debugging and monitoring purposes. For stratum 1 (reference
this is a four-octet, left-justified, zero-padded ASCII string clock) this is a four-octet, left-justified, zero-padded ASCII string
assigned to the reference clock. The authoritative list of Reference assigned to the reference clock. The authoritative list of Reference
Identifiers is maintained by IANA, however any string begining with Identifiers is maintained by IANA, however any string beginning with
the ASCII character "X" is reserved for unregistered experimentation the ASCII character "X" is reserved for unregistered experimentation
and developent.The identifiers in Figure 12 have been used as ASCII and developent.The identifiers in Figure 12 have been used as ASCII
identifiers: identifiers:
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| ID | Clock Source | | ID | Clock Source |
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| GOES | Geosynchronous Orbit Environment Satellite | | GOES | Geosynchronous Orbit Environment Satellite |
| GPS | Global Position System | | GPS | Global Position System |
| GAL | Galileo Positioning System | | GAL | Galileo Positioning System |
skipping to change at page 23, line 27 skipping to change at page 23, line 27
Transmit Timestamp (xmt): Time at the server when the response left Transmit Timestamp (xmt): Time at the server when the response left
for the client, in NTP timestamp format. for the client, in NTP timestamp format.
Destination Timestamp (dst): Time at the client when the reply Destination Timestamp (dst): Time at the client when the reply
arrived from the server, in NTP timestamp format. arrived from the server, in NTP timestamp format.
Note: Destination Timestamp field is not included as a header field; Note: Destination Timestamp field is not included as a header field;
it is determined upon arrival of the packet and made available in the it is determined upon arrival of the packet and made available in the
packet buffer data structure. packet buffer data structure.
If NTP has access to the physical layer, then the timestamps are
associated with the beginning of the symbol after the start of frame.
Otherwise, implementations should attempt to associate the timestamp
to the earliest accessible point in the frame.
The MAC consists of the Key Identifier followed by the Message The MAC consists of the Key Identifier followed by the Message
Digest. The message digest, or cryptosum, is calculated as in [16] Digest. The message digest, or cryptosum, is calculated as in
over all NTP header and optional extension fields, but not the MAC [RFC1321] over all NTP header and optional extension fields, but not
itself. the MAC itself.
Extension Field n: See Section 7.5 for a description of the format of Extension Field n: See Section 7.5 for a description of the format of
this field. this field.
Key Identifier (keyid): 32-bit unsigned integer used by the client Key Identifier (keyid): 32-bit unsigned integer used by the client
and server to designate a secret 128-bit MD5 key. and server to designate a secret 128-bit MD5 key.
Message Digest (digest): 128-bit bitstring computed by the keyed MD5 Message Digest (digest): 128-bit bitstring computed by the keyed MD5
message digest computed over all the words in the header and message digest computed over all the words in the header and
extension fields, but not the MAC itself. extension fields, but not the MAC itself.
skipping to change at page 24, line 18 skipping to change at page 24, line 23
actions: actions:
a. For kiss codes: DENY, RSTR the client MUST demobilize any a. For kiss codes: DENY, RSTR the client MUST demobilize any
associations to that server and stop sending packets to that associations to that server and stop sending packets to that
server; server;
b. For kiss code: RATE the client MUST immediately reduce its b. For kiss code: RATE the client MUST immediately reduce its
polling interval to that server and continue to reduce it each polling interval to that server and continue to reduce it each
time it receives a RATE kiss code. time it receives a RATE kiss code.
c. Kiss codes begining with the ASCII character "X" are for c. Kiss codes beginning with the ASCII character "X" are for
unregistered experimentation and development and MUST be ignored unregistered experimentation and development and MUST be ignored
if not recognized. if not recognized.
d. Other than the above conditions, KoD packets have no protocol d. Other than the above conditions, KoD packets have no protocol
significance and are discarded after inspection. significance and are discarded after inspection.
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| Code | Meaning | | Code | Meaning |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| ACST | The association belongs to a unicast server | | ACST | The association belongs to a unicast server |
skipping to change at page 25, line 5 skipping to change at page 25, line 31
| RATE | Rate exceeded. The server has temporarily denied access | | RATE | Rate exceeded. The server has temporarily denied access |
| | because the client exceeded the rate threshold | | | because the client exceeded the rate threshold |
| RMOT | Alteration of association from a remote host running | | RMOT | Alteration of association from a remote host running |
| | ntpdc. | | | ntpdc. |
| STEP | A step change in system time has occurred, but the | | STEP | A step change in system time has occurred, but the |
| | association has not yet resynchronized | | | association has not yet resynchronized |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
Figure 13: Kiss Codes Figure 13: Kiss Codes
The Receive Timestamp and the Transmit Timestamp (set by the server)
are undefined when in a KoD packet and MUST NOT be relied upon to
have valid values and MUST be discarded.
7.5. NTP Extension Field Format 7.5. NTP Extension Field Format
In NTPv4 one or more extension fields can be inserted after the In NTPv4 one or more extension fields can be inserted after the
header and before the MAC, which is always present when an extension header and before the MAC, which is always present when an extension
field is present. Other than defining the field format, this field is present. Other than defining the field format, this
document makes no use of the field contents. An extension field document makes no use of the field contents. An extension field
contains a request or response message in the format shown in contains a request or response message in the format shown in
Figure 14. Figure 14.
0 1 2 3 0 1 2 3
skipping to change at page 32, line 26 skipping to change at page 33, line 26
Appendix A.5.4 implements access restrictions using an access control Appendix A.5.4 implements access restrictions using an access control
list (ACL). There is no specific method required for access control, list (ACL). There is no specific method required for access control,
although it is recommended that implementations include such a although it is recommended that implementations include such a
scheme, which is similar to many others now in widespread use. scheme, which is similar to many others now in widespread use.
Format checks require correct field length and alignment, acceptable Format checks require correct field length and alignment, acceptable
version number (1-4) and correct extension field syntax, if present. version number (1-4) and correct extension field syntax, if present.
There is no specific requirement for authentication; however, if There is no specific requirement for authentication; however, if
authentication is implemented, the symmetric key scheme described in authentication is implemented, the symmetric key scheme described in
Appendix A.2 must be among the supported schemes. This scheme uses Appendix A.2 must be among the supported schemes. This scheme uses
the MD5 keyed hash algorithm described in [16]. the MD5 keyed hash algorithm described in [RFC1321].
Next, the association table is searched for matching source address Next, the association table is searched for matching source address
and source port using the find_assoc() routine in Appendix A.5.1. and source port using the find_assoc() routine in Appendix A.5.1.
Figure 20 is a dispatch table where the columns correspond to the Figure 20 is a dispatch table where the columns correspond to the
packet mode and rows correspond to the association mode. The packet mode and rows correspond to the association mode. The
intersection of the association and packet modes dispatches intersection of the association and packet modes dispatches
processing to one of the following steps. processing to one of the following steps.
+------------------+---------------------------------------+ +------------------+---------------------------------------+
| | Packet Mode | | | Packet Mode |
skipping to change at page 38, line 48 skipping to change at page 39, line 48
the system clock to the correct time. the system clock to the correct time.
The cluster algorithm selects one of the survivors as the system The cluster algorithm selects one of the survivors as the system
peer. The associated statistics (theta, delta, epsilon, jitter, t) peer. The associated statistics (theta, delta, epsilon, jitter, t)
are used to construct the system variables inherited by dependent are used to construct the system variables inherited by dependent
servers and clients and made available to other applications running servers and clients and made available to other applications running
on the same machine. on the same machine.
11.1. System Process Variables 11.1. System Process Variables
Figure 25 summarizes the common names, formula names and a short Figure 23 summarizes the common names, formula names and a short
description of each system variable. Unless noted otherwise, all description of each system variable. Unless noted otherwise, all
variables have assumed prefix s. variables have assumed prefix s.
+-----------+------------+------------------------+ +-----------+------------+------------------------+
| Name | Formula | Description | | Name | Formula | Description |
+-----------+------------+------------------------+ +-----------+------------+------------------------+
| t | t | update time | | t | t | update time |
| p | p | system peer identifier | | p | p | system peer identifier |
| leap | leap | leap indicator | | leap | leap | leap indicator |
| stratum | stratum | stratum | | stratum | stratum | stratum |
skipping to change at page 39, line 24 skipping to change at page 40, line 24
| jitter | PSI | combined jitter | | jitter | PSI | combined jitter |
| rootdelay | DELTA | root delay | | rootdelay | DELTA | root delay |
| rootdisp | EPSILON | root dispersion | | rootdisp | EPSILON | root dispersion |
| v | v | survivor list | | v | v | survivor list |
| refid | refid | reference ID | | refid | refid | reference ID |
| reftime | reftime | reference time | | reftime | reftime | reference time |
| NMIN | 3 | minimum survivors | | NMIN | 3 | minimum survivors |
| CMIN | 1 | minimum candidates | | CMIN | 1 | minimum candidates |
+-----------+------------+------------------------+ +-----------+------------+------------------------+
Figure 25: System Process Variables Figure 23: System Process Variables
Except for the t, p, offset and jitter variables and the NMIN and Except for the t, p, offset and jitter variables and the NMIN and
CMIN constants, the variables have the same format and interpretation CMIN constants, the variables have the same format and interpretation
as the peer variables of the same name. The NMIN and CMIN parameters as the peer variables of the same name. The NMIN and CMIN parameters
are used by the selection and cluster algorithms described in the are used by the selection and cluster algorithms described in the
next section. next section.
The t variable is the seconds counter at the last update determined The t variable is the seconds counter at the last update determined
by the clock_update() routine in Appendix A.5.5.4. The p variable is by the clock_update() routine in Appendix A.5.5.4. The p variable is
the system peer identifier determined by the cluster() routine in the system peer identifier determined by the cluster() routine in
skipping to change at page 39, line 51 skipping to change at page 40, line 51
The offset and jitter variables are determined by the combine() The offset and jitter variables are determined by the combine()
routine in Section 11.2.3. These values represent the best and final routine in Section 11.2.3. These values represent the best and final
offset and jitter used to discipline the system clock. Initially, offset and jitter used to discipline the system clock. Initially,
all variables are cleared to zero, then the leap is set to 3 all variables are cleared to zero, then the leap is set to 3
(unsynchronized) and stratum is set to MAXSTRAT (16). Remember that (unsynchronized) and stratum is set to MAXSTRAT (16). Remember that
MAXSTRAT is mapped to zero in the transmitted packet. MAXSTRAT is mapped to zero in the transmitted packet.
11.2. System Process Operations 11.2. System Process Operations
Figure 26 summarizes the system process operations performed by the Figure 24 summarizes the system process operations performed by the
clock_select() routine. The selection algorithm described in clock_select() routine. The selection algorithm described in
Section 11.2.1 produces a majority clique of presumed correct Section 11.2.1 produces a majority clique of presumed correct
candidates (truechimers) based on agreement principles. The cluster candidates (truechimers) based on agreement principles. The cluster
algorithm described in Section 11.2.2 discards outlyers to produce algorithm described in Section 11.2.2 discards outlyers to produce
the most accurate survivors. The combine algorithm described in the most accurate survivors. The combine algorithm described in
Section 11.2.3 provides the best and final offset for the clock Section 11.2.3 provides the best and final offset for the clock
discipline algorithm described in Appendix A.5.5.6. If the selection discipline algorithm described in Appendix A.5.5.6. If the selection
algorithm cannot produce a majority clique, or if it cannot produce algorithm cannot produce a majority clique, or if it cannot produce
at least CMIN survivors, the system process exits without at least CMIN survivors, the system process exits without
disciplining the system clock. If successful, the cluster algorithm disciplining the system clock. If successful, the cluster algorithm
skipping to change at page 41, line 47 skipping to change at page 42, line 47
+-----------------+ V no +-----------------+ V no
| s.p = NULL | +-------------------+ | s.p = NULL | +-------------------+
+-----------------+ | s.p = v_0.p | +-----------------+ | s.p = v_0.p |
| +-------------------+ | +-------------------+
V | V |
+-----------------+ V +-----------------+ V
| return (UNSYNC) | +-------------------+ | return (UNSYNC) | +-------------------+
+-----------------+ | return (SYNC) | +-----------------+ | return (SYNC) |
+-------------------+ +-------------------+
Figure 26: clock_select() Routine Figure 24: clock_select() Routine
11.2.1. Selection Algorithm 11.2.1. Selection Algorithm
Note that the selection and cluster algorithms are described Note that the selection and cluster algorithms are described
separately, but combined in the code skeleton. The selection separately, but combined in the code skeleton. The selection
algorithm operates to find an intersection interval containing a algorithm operates to find an intersection interval containing a
majority clique of truechimers using Byzantine agreement principles majority clique of truechimers using Byzantine agreement principles
originally proposed by Marzullo [8], but modified to improve originally proposed by Marzullo [ref6], but modified to improve
accuracy. An overview of the algorithm is given below and in the accuracy. An overview of the algorithm is given below and in the
first half of the clock_select() routine in Appendix A.5.5.1. first half of the clock_select() routine in Appendix A.5.5.1.
First, those servers which are unusable according to the rules of the First, those servers which are unusable according to the rules of the
protocol are detected and discarded by the accept() routine in protocol are detected and discarded by the accept() routine in
Appendix A.5.5.3. Next, a set of tuples (p, type, edge) is generated Appendix A.5.5.3. Next, a set of tuples (p, type, edge) is generated
for the remaining candidates. Here, p is the association identifier for the remaining candidates. Here, p is the association identifier
and type identifies the upper (+1), middle (0) and lower (-1) and type identifies the upper (+1), middle (0) and lower (-1)
endpoints of a correctness interval centered on theta for that endpoints of a correctness interval centered on theta for that
candidate. This results in three tuples, lowpoint (p, -1, theta - candidate. This results in three tuples, lowpoint (p, -1, theta -
skipping to change at page 45, line 13 skipping to change at page 46, line 13
the offset is greater than the panic threshold PANICT (1000 s) and the offset is greater than the panic threshold PANICT (1000 s) and
SHOULD cause the program to exit with a diagnostic message to the SHOULD cause the program to exit with a diagnostic message to the
system log. STEP means the offset is less than the panic threshold, system log. STEP means the offset is less than the panic threshold,
but greater than the step threshold STEPT (125 ms). In this case the but greater than the step threshold STEPT (125 ms). In this case the
clock is stepped to the correct offset, but since this means all peer clock is stepped to the correct offset, but since this means all peer
data have been invalidated, all associations MUST be reset and the data have been invalidated, all associations MUST be reset and the
client begins as at initial start. client begins as at initial start.
ADJ means the offset is less than the step threshold and thus a valid ADJ means the offset is less than the step threshold and thus a valid
update. In this case the system variables are updated from the peer update. In this case the system variables are updated from the peer
variables as shown in Figure 28. variables as shown in Figure 25.
+-------------------------------------------+ +-------------------------------------------+
| System Variable <-- System Peer Variable | | | System Variable <-- System Peer Variable | |
+-------------------------------------------+ +-------------------------------------------+
| s.leap <-- p.leap | | s.leap <-- p.leap |
| s.stratum <-- p.stratum + 1 | | s.stratum <-- p.stratum + 1 |
| s.offset <-- THETA | | s.offset <-- THETA |
| s.jitter <-- PSI | | s.jitter <-- PSI |
| s.rootdelay <-- p.delta_r + delta | | s.rootdelay <-- p.delta_r + delta |
| s.rootdisp <-- p.epsilon_r + p.epsilon + | | s.rootdisp <-- p.epsilon_r + p.epsilon + |
| p.psi + PHI * (s.t - p.t) | | p.psi + PHI * (s.t - p.t) |
| + |THETA| | | + |THETA| |
| s.refid <-- p.refid | | s.refid <-- p.refid |
| s.reftime <-- p.reftime | | s.reftime <-- p.reftime |
| s.t <-- p.t | | s.t <-- p.t |
+-------------------------------------------+ +-------------------------------------------+
Figure 28: System Variables Update Figure 25: System Variables Update
There is an important detail not shown. The dispersion increment There is an important detail not shown. The dispersion increment
(p.epsilon + p.psi + PHI * (s.t - p.t) + |THETA|) is bounded from (p.epsilon + p.psi + PHI * (s.t - p.t) + |THETA|) is bounded from
below by MINDISP. In subnets with very fast processors and networks below by MINDISP. In subnets with very fast processors and networks
and very small delay and dispersion this forces a monotone-definite and very small delay and dispersion this forces a monotone-definite
increase in s.rootdisp (EPSILON), which avoids loops between peers increase in s.rootdisp (EPSILON), which avoids loops between peers
operating at the same stratum. operating at the same stratum.
The system variables are available to dependent application programs The system variables are available to dependent application programs
as nominal performance statistics. The system offset THETA is the as nominal performance statistics. The system offset THETA is the
skipping to change at page 46, line 16 skipping to change at page 47, line 16
11.3. Clock Discipline Algorithm 11.3. Clock Discipline Algorithm
The NTPv4 clock discipline algorithm, shortened to discipline in the The NTPv4 clock discipline algorithm, shortened to discipline in the
following, functions as a combination of two philosophically quite following, functions as a combination of two philosophically quite
different feedback control systems. In a phase-locked loop (PLL) different feedback control systems. In a phase-locked loop (PLL)
design, periodic phase updates at update intervals mu seconds are design, periodic phase updates at update intervals mu seconds are
used directly to minimize the time error and indirectly the frequency used directly to minimize the time error and indirectly the frequency
error. In a frequency-locked loop (FLL) design, periodic frequency error. In a frequency-locked loop (FLL) design, periodic frequency
updates at intervals mu are used directly to minimize the frequency updates at intervals mu are used directly to minimize the frequency
error and indirectly the time error. As shown in [5], a PLL usually error and indirectly the time error. As shown in [ref7], a PLL
works better when network jitter dominates, while a FLL works better usually works better when network jitter dominates, while a FLL works
when oscillator wander dominates. This section contains an outline better when oscillator wander dominates. This section contains an
of how the NTPv4 design works. An in-depth discussion of the design outline of how the NTPv4 design works. An in-depth discussion of the
principles is provided in [5], which also includes a performance design principles is provided in [ref7], which also includes a
analysis. performance analysis.
The discipline is implemented as the feedback control system shown in The discipline is implemented as the feedback control system shown in
Figure 29. The variable theta_r represents the combine algorithm Figure 26. The variable theta_r represents the combine algorithm
offset (reference phase) and theta_c the VFO offset (control phase). offset (reference phase) and theta_c the VFO offset (control phase).
Each update produces a signal V_d representing the instantaneous Each update produces a signal V_d representing the instantaneous
phase difference theta_r - theta_c. The clock filter for each server phase difference theta_r - theta_c. The clock filter for each server
functions as a tapped delay line, with the output taken at the tap functions as a tapped delay line, with the output taken at the tap
selected by the clock filter algorithm. The selection, cluster and selected by the clock filter algorithm. The selection, cluster and
combine algorithms combine the data from multiple filters to produce combine algorithms combine the data from multiple filters to produce
the signal V_s. The loop filter, with impulse response F(t), the signal V_s. The loop filter, with impulse response F(t),
produces the signal V_c which controls the VFO frequency omega_c and produces the signal V_c which controls the VFO frequency omega_c and
thus the integral of the phase theta_c which closes the loop. The thus the integral of the phase theta_c which closes the loop. The
V_c signal is generated by the clock adjust process in Section 12. V_c signal is generated by the clock adjust process in Section 12.
skipping to change at page 47, line 25 skipping to change at page 48, line 25
----- ....................................... | ----- ....................................... |
^ . Loop Filter . | ^ . Loop Filter . |
| . +---------+ x +-------------+ . | | . +---------+ x +-------------+ . |
| V_c . | |<-----| | . | | V_c . | |<-----| | . |
+------.-| Clock | y | Phase/Freq |<---------+ +------.-| Clock | y | Phase/Freq |<---------+
. | Adjust |<-----| Prediction | . . | Adjust |<-----| Prediction | .
. | | | | . . | | | | .
. +---------+ +-------------+ . . +---------+ +-------------+ .
....................................... .......................................
Figure 29: Clock Discipline Feedback Loop Figure 26: Clock Discipline Feedback Loop
Ordinarily, the pseudo-linear feedback loop described above operates Ordinarily, the pseudo-linear feedback loop described above operates
to discipline the system clock. However, there are cases where a to discipline the system clock. However, there are cases where a
nonlinear algorithm offers considerable improvement. One case is nonlinear algorithm offers considerable improvement. One case is
when the discipline starts without knowledge of the intrinsic clock when the discipline starts without knowledge of the intrinsic clock
frequency. The pseudo-linear loop takes several hours to develop an frequency. The pseudo-linear loop takes several hours to develop an
accurate measurement and during most of that time the poll interval accurate measurement and during most of that time the poll interval
cannot be increased. The nonlinear loop described below does this in cannot be increased. The nonlinear loop described below does this in
15 minutes. Another case is when occasional bursts of large jitter 15 minutes. Another case is when occasional bursts of large jitter
are present due to congested network links. The state machine are present due to congested network links. The state machine
described below resists error bursts lasting less than 15 minutes. described below resists error bursts lasting less than 15 minutes.
Figure 30 contains a summary of the variables and parameters Figure 27 contains a summary of the variables and parameters
including the variables (lower case) or parameters (upper case) name, including the variables (lower case) or parameters (upper case) name,
formula name and short description. Unless noted otherwise, all formula name and short description. Unless noted otherwise, all
variables have assumed prefix c. The variables t, tc, state, hyster variables have assumed prefix c. The variables t, tc, state, hyster
and count are integers; the remaining variables are floating doubles. and count are integers; the remaining variables are floating doubles.
The function of each will be explained in the algorithm descriptions The function of each will be explained in the algorithm descriptions
below. below.
+--------+------------+--------------------------+ +--------+------------+--------------------------+
| Name | Formula | Description | | Name | Formula | Description |
+--------+------------+--------------------------+ +--------+------------+--------------------------+
skipping to change at page 48, line 27 skipping to change at page 49, line 27
| hyster | hyster | hysteresis counter | | hyster | hyster | hysteresis counter |
| STEPT | 125 | step threshold (.125 s) | | STEPT | 125 | step threshold (.125 s) |
| WATCH | 900 | stepout thresh(s) | | WATCH | 900 | stepout thresh(s) |
| PANICT | 1000 | panic threshold (1000 s) | | PANICT | 1000 | panic threshold (1000 s) |
| LIMIT | 30 | hysteresis limit | | LIMIT | 30 | hysteresis limit |
| PGATE | 4 | hysteresis gate | | PGATE | 4 | hysteresis gate |
| TC | 16 | time constant scale | | TC | 16 | time constant scale |
| AVG | 8 | averaging constant | | AVG | 8 | averaging constant |
+--------+------------+--------------------------+ +--------+------------+--------------------------+
Figure 30: Clock Discipline Variables and Parameters Figure 27: Clock Discipline Variables and Parameters
The discipline is implemented by the local_clock() routine, which is The discipline is implemented by the local_clock() routine, which is
called from the clock_update() routine. The local_clock() routine in called from the clock_update() routine. The local_clock() routine in
Appendix A.5.5.6 has two parts; the first implements the clock state Appendix A.5.5.6 has two parts; the first implements the clock state
machine and the second determines the time constant and thus the poll machine and the second determines the time constant and thus the poll
interval. interval.
The local_clock() routine exits immediately if the offset is greater The local_clock() routine exits immediately if the offset is greater
than the panic threshold PANICT (1000 s). The state transition than the panic threshold PANICT (1000 s). The state transition
function is implemented by the rstclock() function in function is implemented by the rstclock() function in
Appendix A.5.5.7. Figure 31 shows the state transition function used Appendix A.5.5.7. Figure 28 shows the state transition function used
by this routine. It has four columns showing respectively the state by this routine. It has four columns showing respectively the state
name, predicate and action if the offset theta is less than the step name, predicate and action if the offset theta is less than the step
threshold, the predicate and actions otherwise, and finally some threshold, the predicate and actions otherwise, and finally some
comments. comments.
+-------+---------------------+-------------------+--------------+ +-------+---------------------+-------------------+--------------+
| State | theta < STEP | theta > STEP | Comments | | State | theta < STEP | theta > STEP | Comments |
+-------+---------------------+-------------------+--------------+ +-------+---------------------+-------------------+--------------+
| NSET | ->FREQ | ->FREQ | no frequency | | NSET | ->FREQ | ->FREQ | no frequency |
| | adjust time | step time | file | | | adjust time | step time | file |
skipping to change at page 49, line 30 skipping to change at page 50, line 30
| | else ->SYNC | else ->SYNC | frequency | | | else ->SYNC | else ->SYNC | frequency |
| | step freq | step freq | | | | step freq | step freq | |
| | adjust time | adjust time | | | | adjust time | adjust time | |
+-------+---------------------+-------------------+--------------+ +-------+---------------------+-------------------+--------------+
| SYNC | ->SYNC | if < 900 s ->SPIK | normal | | SYNC | ->SYNC | if < 900 s ->SPIK | normal |
| | adjust freq | else ->SYNC | operation | | | adjust freq | else ->SYNC | operation |
| | adjust time | step freq | | | | adjust time | step freq | |
| | | step time | | | | | step time | |
+-------+---------------------+-------------------+--------------+ +-------+---------------------+-------------------+--------------+
Figure 31: State Transition Function Figure 28: State Transition Function
In the table entries the next state is identified by the arrow -> In the table entries the next state is identified by the arrow ->
with the actions listed below. Actions such as adjust time and with the actions listed below. Actions such as adjust time and
adjust frequency are implemented by the PLL/FLL feedback loop in the adjust frequency are implemented by the PLL/FLL feedback loop in the
local_clock() routine. A step clock action is implemented by setting local_clock() routine. A step clock action is implemented by setting
the clock directly, but this is done only after the stepout threshold the clock directly, but this is done only after the stepout threshold
WATCH (900 s) when the offset is more than the step threshold STEPT WATCH (900 s) when the offset is more than the step threshold STEPT
(.125 s). This resists clock steps under conditions of extreme (.125 s). This resists clock steps under conditions of extreme
network congestion. network congestion.
skipping to change at page 50, line 35 skipping to change at page 51, line 35
13. Poll Process 13. Poll Process
Each association supports a poll process that runs at regular Each association supports a poll process that runs at regular
intervals to construct and send packets in symmetric, client and intervals to construct and send packets in symmetric, client and
broadcast server associations. It runs continuously, whether or not broadcast server associations. It runs continuously, whether or not
servers are reachable in order to manage the clock filter and reach servers are reachable in order to manage the clock filter and reach
register. register.
13.1. Poll Process Variables 13.1. Poll Process Variables
Figure 32 summarizes the common names, formula names and a short Figure 29 summarizes the common names, formula names and a short
description of the poll process variables(lower case) and parameters description of the poll process variables(lower case) and parameters
(upper case). Unless noted otherwise, all variables have assumed (upper case). Unless noted otherwise, all variables have assumed
prefix p. prefix p.
+---------+---------+--------------------+ +---------+---------+--------------------+
| Name | Formula | Description | | Name | Formula | Description |
+---------+---------+--------------------+ +---------+---------+--------------------+
| hpoll | hpoll | host poll exponent | | hpoll | hpoll | host poll exponent |
| last | last | last poll time | | last | last | last poll time |
| next | next | next poll time | | next | next | next poll time |
| reach | reach | reach register | | reach | reach | reach register |
| unreach | unreach | unreach counter | | unreach | unreach | unreach counter |
| UNREACH | 24 | unreach limit | | UNREACH | 24 | unreach limit |
| BCOUNT | 8 | burst count | | BCOUNT | 8 | burst count |
| BURST | flag | burst enable | | BURST | flag | burst enable |
| IBURST | flag | iburst enable | | IBURST | flag | iburst enable |
+---------+---------+--------------------+ +---------+---------+--------------------+
Figure 32: Poll Process Variables and Parameters Figure 29: Poll Process Variables and Parameters
The poll process variables are allocated in the association data The poll process variables are allocated in the association data
structure along with the peer process variables. Following is a structure along with the peer process variables. Following is a
detailed description of the variables. The parameters will be called detailed description of the variables. The parameters will be called
out in the following text. out in the following text.
hpoll: signed integer representing the poll exponent, in log2 seconds hpoll: signed integer representing the poll exponent, in log2 seconds
last: integer representing the seconds counter when the most recent last: integer representing the seconds counter when the most recent
packet was sent packet was sent
skipping to change at page 52, line 43 skipping to change at page 53, line 43
server is reachable and unreach is set to zero; otherwise, unreach is server is reachable and unreach is set to zero; otherwise, unreach is
incremented by one for each poll to the maximum UNREACH. Thereafter incremented by one for each poll to the maximum UNREACH. Thereafter
for each poll hpoll is increased by one, which doubles the poll for each poll hpoll is increased by one, which doubles the poll
interval up to the maximum MAXPOLL determined by the poll_update() interval up to the maximum MAXPOLL determined by the poll_update()
routine. When the server again becomes reachable, unreach is set to routine. When the server again becomes reachable, unreach is set to
zero, hpoll is reset to the tc system variable and operation resumes zero, hpoll is reset to the tc system variable and operation resumes
normally. normally.
A packet is sent by the xmit_packet() routine in Appendix A.3. Some A packet is sent by the xmit_packet() routine in Appendix A.3. Some
header values are copied from the peer variables left by a previous header values are copied from the peer variables left by a previous
packet and others from the system variables. Figure 33 shows which packet and others from the system variables. Figure 30 shows which
values are copied to each header field. In those implementations values are copied to each header field. In those implementations
using floating double data types for root delay and root dispersion, using floating double data types for root delay and root dispersion,
these must be converted to NTP short format. All other fields are these must be converted to NTP short format. All other fields are
either copied intact from peer and system variables or struck as a either copied intact from peer and system variables or struck as a
timestamp from the system clock. timestamp from the system clock.
+-----------------------------------+ +-----------------------------------+
| Packet Variable <-- Variable | | Packet Variable <-- Variable |
+-----------------------------------+ +-----------------------------------+
| x.leap <-- s.leap | | x.leap <-- s.leap |
skipping to change at page 53, line 25 skipping to change at page 54, line 25
| x.rootdisp <-- s.rootdisp | | x.rootdisp <-- s.rootdisp |
| x.refid <-- s.refid | | x.refid <-- s.refid |
| x.reftime <-- s.reftime | | x.reftime <-- s.reftime |
| x.org <-- p.xmt | | x.org <-- p.xmt |
| x.rec <-- p.dst | | x.rec <-- p.dst |
| x.xmt <-- clock | | x.xmt <-- clock |
| x.keyid <-- p.keyid | | x.keyid <-- p.keyid |
| x.digest <-- md5 digest | | x.digest <-- md5 digest |
+-----------------------------------+ +-----------------------------------+
Figure 33: xmit_packet Packet Header Figure 30: xmit_packet Packet Header
The poll_update() routine shown in Appendix A.5.7.2 is called when a The poll_update() routine shown in Appendix A.5.7.2 is called when a
valid packet is received and immediately after a poll message has valid packet is received and immediately after a poll message has
been sent. If in a burst, the poll interval is fixed at 2 s; been sent. If in a burst, the poll interval is fixed at 2 s;
otherwise, the host poll exponent hpoll is set to the minimum of otherwise, the host poll exponent hpoll is set to the minimum of
ppoll from the last packet received and hpoll from the poll() ppoll from the last packet received and hpoll from the poll()
routine, but not less than MINPOLL nor greater than MAXPOLL. Thus routine, but not less than MINPOLL nor greater than MAXPOLL. Thus
the clock discipline can be oversampled, but not undersampled. This the clock discipline can be oversampled, but not undersampled. This
is necessary to preserve subnet dynamic behavior and protect against is necessary to preserve subnet dynamic behavior and protect against
protocol errors. protocol errors.
The poll exponent is converted to an interval which when added to the The poll exponent is converted to an interval which when added to the
last variable determines the next variable and thus the time for the last variable determines the next variable and thus the time for the
next poll. Finally, the last variable is set to the current seconds next poll. Finally, the last variable is set to the current seconds
counter. counter.
14. Simple Network Time Protocol (SNTP) 14. Simple Network Time Protocol (SNTP)
Primary servers and clients complying with a subset of NTP, called Primary servers and clients complying with a subset of NTP, called
the Simple Network Time Protocol (SNTPv4) [2], do not need to the Simple Network Time Protocol (SNTPv4) [RFC4330], do not need to
implement the mitigation algorithms described in Section 9 and implement the mitigation algorithms described in Section 9 and
following sections. SNTP is intended for primary servers equipped following sections. SNTP is intended for primary servers equipped
with a single reference clock, as well as for clients with a single with a single reference clock, as well as for clients with a single
upstream server and no dependent clients. The fully developed NTPv4 upstream server and no dependent clients. The fully developed NTPv4
implementation is intended for secondary servers with multiple implementation is intended for secondary servers with multiple
upstream servers and multiple downstream servers or clients. Other upstream servers and multiple downstream servers or clients. Other
than these considerations, NTP and SNTP servers and clients are than these considerations, NTP and SNTP servers and clients are
completely interoperable and can be intermixed in NTP subnets. completely interoperable and can be intermixed in NTP subnets.
An SNTP primary server implementing the on-wire protocol described in An SNTP primary server implementing the on-wire protocol described in
Section 8 has no upstream servers except a single reference clock. Section 8 has no upstream servers except a single reference clock.
In principle, it is indistinguishable from an NTP primary server that In principle, it is indistinguishable from an NTP primary server that
has the mitigation algorithms and therefore capable of mitigating has the mitigation algorithms and therefore capable of mitigating
between multiple reference clocks. between multiple reference clocks.
Upon receiving a client request, an SNTP primary server constructs Upon receiving a client request, an SNTP primary server constructs
and sends the reply packet as described in Figure 34. Note that the and sends the reply packet as described in Figure 31. Note that the
dispersion field in the packet header must be updated as described in dispersion field in the packet header must be updated as described in
Section 5. Section 5.
+-----------------------------------+ +-----------------------------------+
| Packet Variable <-- Variable | | Packet Variable <-- Variable |
+-----------------------------------+ +-----------------------------------+
| x.leap <-- s.leap | | x.leap <-- s.leap |
| x.version <-- r.version | | x.version <-- r.version |
| x.mode <-- 4 | | x.mode <-- 4 |
| x.stratum <-- s.stratum | | x.stratum <-- s.stratum |
skipping to change at page 54, line 38 skipping to change at page 55, line 38
| x.rootdisp <-- s.rootdisp | | x.rootdisp <-- s.rootdisp |
| x.refid <-- s.refid | | x.refid <-- s.refid |
| x.reftime <-- s.reftime | | x.reftime <-- s.reftime |
| x.org <-- r.xmt | | x.org <-- r.xmt |
| x.rec <-- r.dst | | x.rec <-- r.dst |
| x.xmt <-- clock | | x.xmt <-- clock |
| x.keyid <-- r.keyid | | x.keyid <-- r.keyid |
| x.digest <-- md5 digest | | x.digest <-- md5 digest |
+-----------------------------------+ +-----------------------------------+
Figure 34: fast_xmit Packet Header Figure 31: fast_xmit Packet Header
A SNTP client implementing the on-wire protocol has a single server A SNTP client implementing the on-wire protocol has a single server
and no dependent clients. It can operate with any subset of the NTP and no dependent clients. It can operate with any subset of the NTP
on-wire protocol, the simplest approach using only the transmit on-wire protocol, the simplest approach using only the transmit
timestamp of the server packet and ignoring all other fields. timestamp of the server packet and ignoring all other fields.
However, the additional complexity to implement the full on-wire However, the additional complexity to implement the full on-wire
protocol is minimal so that a full implementation is encouraged. protocol is minimal so that a full implementation is encouraged.
15. Security Considerations 15. Security Considerations
NTPv4 provides an optional authentication field that utilizes the MD5 NTPv4 provides an optional authentication field that utilizes the MD5
algorithm. MD5, as the case for SHA-1, is derived from MD4, which algorithm. MD5, as the case for SHA-1, is derived from MD4, which
has long been known to be weak. In 2004, techniques for efficiently has long been known to be weak. In 2004, techniques for efficiently
finding collisions in MD5 were announced. A summary of the finding collisions in MD5 were announced. A summary of the
apropriateness of MD5 can be found in [9]. appropriateness of MD5 can be found in [ref8].
In the case of NTP as specified herein, NTP broadcast clients are In the case of NTP as specified herein, NTP broadcast clients are
vulnerable to disruption by misbehaving or hostile SNTP or NTP vulnerable to disruption by misbehaving or hostile SNTP or NTP
broadcast servers elsewhere in the Internet. Access controls and/or broadcast servers elsewhere in the Internet. Access controls and/or
cryptographic authentication means should be provided for additional cryptographic authentication means should be provided for additional
security in such cases. security in such cases.
Section 8 describes a potential security concern with the replay of Section 8 describes a potential security concern with the replay of
client requests. Following the recommendations in that section client requests. Following the recommendations in that section
provides protection against such attacks. provides protection against such attacks.
skipping to change at page 55, line 29 skipping to change at page 56, line 29
UDP/TCP Port 123 was previously assigned by IANA for this protocol. UDP/TCP Port 123 was previously assigned by IANA for this protocol.
The IANA has assigned the IPv4 multicast group address 224.0.1.1 and The IANA has assigned the IPv4 multicast group address 224.0.1.1 and
the IPv6 multicast address ending :101 for NTP. This document the IPv6 multicast address ending :101 for NTP. This document
introduces NTP extension fields allowing for the development of introduces NTP extension fields allowing for the development of
future extensions to the protocol, where a particular extension is to future extensions to the protocol, where a particular extension is to
be identified by the Field Type sub-field within the extension field. be identified by the Field Type sub-field within the extension field.
IANA is requested to establish and maintain a registry for Extension IANA is requested to establish and maintain a registry for Extension
Field Types associated with this protocol, populating this registry Field Types associated with this protocol, populating this registry
with no initial entries. As future needs arise, new Extension Field with no initial entries. As future needs arise, new Extension Field
Types may be defined. Following the policies outlined in [10], new Types may be defined. Following the policies outlined in [RFC2434],
values are to be defined by IETF consensus. new values are to be defined by IETF consensus.
The IANA is requested to create a new registry for NTP Reference The IANA is requested to create a new registry for NTP Reference
Identifier codes. This should include the current codes defined in Identifier codes. This should include the current codes defined in
Section 7.3, and may be extended on a FCFS basis. The format of the Section 7.3, and may be extended on a FCFS basis. The format of the
registry is: registry is:
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| ID | Clock Source | | ID | Clock Source |
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| GOES | Geosynchronous Orbit Environment Satellite | | GOES | Geosynchronous Orbit Environment Satellite |
| GPS | Global Position System | | GPS | Global Position System |
| ... | ... | | ... | ... |
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
Figure 35: Reference Identifier Codes Figure 32: Reference Identifier Codes
The IANA is requested to create a new registry for NTP Kiss-o'-Death The IANA is requested to create a new registry for NTP Kiss-o'-Death
codes. This should include the current codes defined in Section 7.4, codes. This should include the current codes defined in Section 7.4,
and may be extended on a FCFS basis. The format of the registry is: and may be extended on a FCFS basis. The format of the registry is:
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| Code | Meaning | | Code | Meaning |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| ACST | The association belongs to a unicast server | | ACST | The association belongs to a unicast server |
| AUTH | Server authentication failed | | AUTH | Server authentication failed |
| ... | ... | | ... | ... |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
Figure 36: Kiss Codes Figure 33: Kiss Codes
For both Reference Identifiers and Kiss-o'-Death codes, IANA is For both Reference Identifiers and Kiss-o'-Death codes, IANA is
requested to never assign a code begining with the character "X", as requested to never assign a code beginning with the character "X", as
this is reserved for experimentation and development. this is reserved for experimentation and development.
17. Acknowledgements 17. Acknowledgements
The editors would like to thank Karen O'Donoghue, Brian Haberman, The editors would like to thank Karen O'Donoghue, Brian Haberman,
Greg Dowd, Mark Elliot, and Harlan Stenn for technical reviews of Greg Dowd, Mark Elliot, Harlan Stenn, Yaakov Stein, Stewart Bryant,
this document. and Danny Mayer for technical reviews and specific text contributions
to this document.
18. References 18. References
18.1. Informative References 18.1. Informative References
[1] Mills, D., "Network Time Protocol (Version 3) Specification, [CGPM] Bureau International des Poids et Mesures, "Comptes Rendus
Implementation", RFC 1305, March 1992. de la 15e CGPM", 1976.
[2] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for [ITU-R_TF.460]
IPv4, IPv6 and OSI", RFC 4330, January 2006. International Telecommunications Union, "ITU-R TF.460
Standard-frequency and time-signal emissions",
February 2002.
[3] Mills, D.L., "The Autokey security architecture, protocol and [RFC1305] Mills, D., "Network Time Protocol (Version 3)
algorithms. Electrical and Computer Engineering Technical Specification, Implementation", RFC 1305, March 1992.
Report 06-1-1", NDSS , January 2006.
[4] Mills, D.L., Electrical and Computer Engineering Technical [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Report 06-6-1, NDSS, June 2006., "Network Time Protocol Version IANA Considerations Section in RFCs", BCP 26, RFC 2434,
4 Reference and Implementation Guide.", 2006. October 1998.
[5] Mills, D.L., "Computer Network Time Synchronization - the [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
Network Time Protocol. CRC Press, 304pp.", 2006. for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[6] International Telecommunications Union, "ITU-R TF.460 Standard- [ref3] Mills, D.L., "The Autokey security architecture, protocol
frequency and time-signal emissions", February 2002. and algorithms. Electrical and Computer Engineering
Technical Report 06-1-1", NDSS , January 2006.
[7] Bureau International des Poids et Mesures, "Comptes Rendus de [ref6] Marzullo and S. Owicki, "Maintaining the time in a
la 15e CGPM", 1976. distributed system.", ACM Operating Systems Review 19 ,
July 1985.
[8] Marzullo and S. Owicki, "Maintaining the time in a distributed [ref7] Mills, D.L., "Computer Network Time Synchronization - the
system.", ACM Operating Systems Review 19 , July 1985. Network Time Protocol. CRC Press, 304pp.", 2006.
[9] Bellovin, S. and E. Rescorla, Proceedings of the 13th annual [ref8] Bellovin, S. and E. Rescorla, Proceedings of the 13th
ISOC Network and Distributed System Security Symposium, annual ISOC Network and Distributed System Security
"Deploying a new Hash Algorithm", February 2006. Symposium, "Deploying a new Hash Algorithm",
February 2006.
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [ref9] Mills, D.L., Electrical and Computer Engineering Technical
Considerations Section in RFCs", BCP 26, RFC 2434, Report 06-6-1, NDSS, June 2006., "Network Time Protocol
October 1998. Version 4 Reference and Implementation Guide.", 2006.
18.2. Normative References 18.2. Normative References
[11] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
September 1981. August 1980.
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[13] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
August 1980. RFC 793, September 1981.
[15] Simonsen, K., "Character Mnemonics and Character Sets", [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets",
RFC 1345, June 1992. RFC 1345, June 1992.
[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
April 1992. Requirement Levels", BCP 14, RFC 2119, March 1997.
Appendix A. Code Skeleton Appendix A. Code Skeleton
This appendix is intended to describe the protocol and algorithms of This appendix is intended to describe the protocol and algorithms of
an implementation in a general way using what is called a code an implementation in a general way using what is called a code
skeleton program. This consists of a set of definitions, structures skeleton program. This consists of a set of definitions, structures
and code fragments which illustrate the protocol operations without and code fragments which illustrate the protocol operations without
the complexities of an actual implementation of the protocol. This the complexities of an actual implementation of the protocol. This
program is not an executable and is not designed to run in the program is not an executable and is not designed to run in the
ordinary sense. It is designed to be compiled only in order to ordinary sense. It is designed to be compiled only in order to
skipping to change at page 58, line 31 skipping to change at page 59, line 37
#include <sys/time.h> /* for gettimeofday() and friends */ #include <sys/time.h> /* for gettimeofday() and friends */
#include <stdlib.h> /* for malloc() and friends */ #include <stdlib.h> /* for malloc() and friends */
/* /*
* Data types * Data types
* *
* This program assumes the int data type is 32 bits and the long data * This program assumes the int data type is 32 bits and the long data
* type is 64 bits. The native data type used in most calculations is * type is 64 bits. The native data type used in most calculations is
* floating double. The data types used in some packet header fields * floating double. The data types used in some packet header fields
* require conversion to and from this representation. Some header * require conversion to and from this representation. Some header
* fields involve partitioning an octet, here represeted by individual * fields involve partitioning an octet, here represented by individual
* octets. * octets.
* *
* The 64-bit NTP timestamp format used in timestamp calculations is * The 64-bit NTP timestamp format used in timestamp calculations is
* unsigned seconds and fraction with the decimal point to the left of * unsigned seconds and fraction with the decimal point to the left of
* bit 32. The only operation permitted with these values is * bit 32. The only operation permitted with these values is
* subtraction, yielding a signed 31-bit difference. The 32-bit NTP * subtraction, yielding a signed 31-bit difference. The 32-bit NTP
* short format used in delay and dispersion calculations is seconds and * short format used in delay and dispersion calculations is seconds and
* fraction with the decimal point to the left of bit 16. The only * fraction with the decimal point to the left of bit 16. The only
* operations permitted with these values are addition and * operations permitted with these values are addition and
* multiplication by a constant. * multiplication by a constant.
skipping to change at page 61, line 39 skipping to change at page 62, line 45
* authentication code (MAC) consisting of a key identifier (keyid) and * authentication code (MAC) consisting of a key identifier (keyid) and
* message digest (mac). NTPv4 supports optional extension fields which * message digest (mac). NTPv4 supports optional extension fields which
* are inserted after the the header and before the MAC, but these are * are inserted after the the header and before the MAC, but these are
* not described here. * not described here.
* *
* Receive packet * Receive packet
* *
* Note the dst timestamp is not part of the packet itself. It is * Note the dst timestamp is not part of the packet itself. It is
* captured upon arrival and returned in the receive buffer along with * captured upon arrival and returned in the receive buffer along with
* the buffer length and data. Note that some of the char fields are * the buffer length and data. Note that some of the char fields are
* packed in the actual header, but the details are omited here. * packed in the actual header, but the details are omitted here.
*/ */
struct r { struct r {
ipaddr srcaddr; /* source (remote) address */ ipaddr srcaddr; /* source (remote) address */
ipaddr dstaddr; /* destination (local) address */ ipaddr dstaddr; /* destination (local) address */
char version; /* version number */ char version; /* version number */
char leap; /* leap indicator */ char leap; /* leap indicator */
char mode; /* mode */ char mode; /* mode */
char stratum; /* stratum */ char stratum; /* stratum */
char poll; /* poll interval */ char poll; /* poll interval */
s_char precision; /* precision */ s_char precision; /* precision */
skipping to change at page 67, line 27 skipping to change at page 69, line 27
if (/* frequency file */ 0) { if (/* frequency file */ 0) {
c.freq = /* freq */ 0; c.freq = /* freq */ 0;
rstclock(FSET, 0, 0); rstclock(FSET, 0, 0);
} else { } else {
rstclock(NSET, 0, 0); rstclock(NSET, 0, 0);
} }
c.jitter = LOG2D(s.precision); c.jitter = LOG2D(s.precision);
/* /*
* Read the configuration file and mobilize persistent * Read the configuration file and mobilize persistent
* associations with spcified addresses, version, mode, key ID * associations with specified addresses, version, mode, key ID
* and flags. * and flags.
*/ */
while (/* mobilize configurated associations */ 0) { while (/* mobilize configurated associations */ 0) {
p = mobilize(IPADDR, IPADDR, VERSION, MODE, KEYID, p = mobilize(IPADDR, IPADDR, VERSION, MODE, KEYID,
P_FLAGS); P_FLAGS);
} }
/* /*
* Start the system timer, which ticks once per second. Then * Start the system timer, which ticks once per second. Then
* read packets as they arrive, strike receive timestamp and * read packets as they arrive, strike receive timestamp and
skipping to change at page 69, line 13 skipping to change at page 71, line 13
*/ */
digest digest
md5( md5(
int keyid /* key identifier */ int keyid /* key identifier */
) )
{ {
/* /*
* Compute a keyed cryptographic message digest. The key * Compute a keyed cryptographic message digest. The key
* identifier is associated with a key in the local key cache. * identifier is associated with a key in the local key cache.
* The key is prepended to the packet header and extension fieds * The key is prepended to the packet header and extension fields
* and the result hashed by the MD5 algorithm as described in * and the result hashed by the MD5 algorithm as described in
* RFC-1321. Return a MAC consisting of the 32-bit key ID * RFC-1321. Return a MAC consisting of the 32-bit key ID
* concatenated with the 128-bit digest. * concatenated with the 128-bit digest.
*/ */
return (/* MD5 digest */ 0); return (/* MD5 digest */ 0);
} }
A.3. Kernel Input/Output Interface A.3. Kernel Input/Output Interface
/* /*
skipping to change at page 71, line 40 skipping to change at page 73, line 40
A.5. Peer Process A.5. Peer Process
/* /*
* A crypto-NAK packet includes the NTP header followed by a MAC * A crypto-NAK packet includes the NTP header followed by a MAC
* consisting only of the key identifier with value zero. It tells the * consisting only of the key identifier with value zero. It tells the
* receiver that a prior request could not be properly authenticated, * receiver that a prior request could not be properly authenticated,
* but the NTP header fields are correct. * but the NTP header fields are correct.
* *
* A kiss-o'-death packet is an NTP header with leap 0x3 (NOSYNC) and * A kiss-o'-death packet is an NTP header with leap 0x3 (NOSYNC) and
* stratum 16 (MAXSTRAT. It tells the receiver that something drastic * stratum 16 (MAXSTRAT. It tells the receiver that something drastic
* has happened, as revealled by the kiss code in the refid field. The * has happened, as revealed by the kiss code in the refid field. The
* NTP header fields may or may not be correct. * NTP header fields may or may not be correct.
*/ */
/* /*
* Peer process parameters and constants * Peer process parameters and constants
*/ */
#define SGATE 3 /* spike gate (clock filter */ #define SGATE 3 /* spike gate (clock filter */
#define BDELAY .004 /* broadcast delay (s) */ #define BDELAY .004 /* broadcast delay (s) */
/* /*
* Dispatch codes * Dispatch codes
skipping to change at page 72, line 30 skipping to change at page 74, line 30
/* client */ { DSCRD, DSCRD, DSCRD, PROC, DSCRD }, /* client */ { DSCRD, DSCRD, DSCRD, PROC, DSCRD },
/* server */ { DSCRD, DSCRD, DSCRD, DSCRD, DSCRD }, /* server */ { DSCRD, DSCRD, DSCRD, DSCRD, DSCRD },
/* bcast */ { DSCRD, DSCRD, DSCRD, DSCRD, DSCRD }, /* bcast */ { DSCRD, DSCRD, DSCRD, DSCRD, DSCRD },
/* bclient */ { DSCRD, DSCRD, DSCRD, DSCRD, PROC} /* bclient */ { DSCRD, DSCRD, DSCRD, DSCRD, PROC}
}; };
/* /*
* Miscellaneous macroni * Miscellaneous macroni
* *
* This macro defines the authentication state. If x is 0, * This macro defines the authentication state. If x is 0,
* authentication is optional, othewise it is required. * authentication is optional, otherwise it is required.
*/ */
#define AUTH(x, y) ((x) ? (y) == A_OK : (y) == A_OK || \ #define AUTH(x, y) ((x) ? (y) == A_OK : (y) == A_OK || \
(y) == A_NONE) (y) == A_NONE)
/* /*
* These are used by the clear() routine * These are used by the clear() routine
*/ */
#define BEGIN_CLEAR(p) ((char *)&((p)->begin_clear)) #define BEGIN_CLEAR(p) ((char *)&((p)->begin_clear))
#define END_CLEAR(p) ((char *)&((p)->end_clear)) #define END_CLEAR(p) ((char *)&((p)->end_clear))
#define LEN_CLEAR (END_CLEAR((struct p *)0) - \ #define LEN_CLEAR (END_CLEAR((struct p *)0) - \
skipping to change at page 74, line 40 skipping to change at page 76, line 40
/* /*
if (/* not multicast dstaddr */0) { if (/* not multicast dstaddr */0) {
if (AUTH(p->flags & P_NOTRUST, auth)) if (AUTH(p->flags & P_NOTRUST, auth))
fast_xmit(r, M_SERV, auth); fast_xmit(r, M_SERV, auth);
else if (auth == A_ERROR) else if (auth == A_ERROR)
fast_xmit(r, M_SERV, A_CRYPTO); fast_xmit(r, M_SERV, A_CRYPTO);
return; /* M_SERV packet sent */ return; /* M_SERV packet sent */
} }
/* /*
* This must be manycast. Do not repspond if we are not * This must be manycast. Do not respond if we are not
* synchronized or if our stratum is above the * synchronized or if our stratum is above the
* manycaster. * manycaster.
*/ */
if (s.leap == NOSYNC || s.stratum > r->stratum) if (s.leap == NOSYNC || s.stratum > r->stratum)
return; return;
/* /*
* Respond only if authentication is ok. Note that the * Respond only if authentication is ok. Note that the
* unicast addreess is used, not the multicast. * unicast address is used, not the multicast.
*/ */
if (AUTH(p->flags & P_NOTRUST, auth)) if (AUTH(p->flags & P_NOTRUST, auth))
fast_xmit(r, M_SERV, auth); fast_xmit(r, M_SERV, auth);
return; return;
/* /*
* New manycase client ephemeral association. It is mobilized in * New manycast client ephemeral association. It is mobilized in
* the same version as in the packet. If authentication fails, * the same version as in the packet. If authentication fails,
* ignore the packet. Verify the server packet by comparing the * ignore the packet. Verify the server packet by comparing the
* r->org timestamp in the packet with the p->xmt timestamp in * r->org timestamp in the packet with the p->xmt timestamp in
* the multicast client association. If they match, the server * the multicast client association. If they match, the server
* packet is authentic. Details omitted. * packet is authentic. Details omitted.
*/ */
case MANY: case MANY:
if (!AUTH(p->flags & (P_NOTRUST | P_NOPEER), auth)) if (!AUTH(p->flags & (P_NOTRUST | P_NOPEER), auth))
return; /* authentication error */ return; /* authentication error */
p = mobilize(r->srcaddr, r->dstaddr, r->version, M_CLNT, p = mobilize(r->srcaddr, r->dstaddr, r->version, M_CLNT,
r->keyid, P_EPHEM); r->keyid, P_EPHEM);
break; break;
/* /*
* New symmetric passive ssociation. It is mobilized in the same * New symmetric passive association. It is mobilized in the same
* version as in the packet. If authentication fails, send a * version as in the packet. If authentication fails, send a
* crypto-NAK packet. If restrict no-moblize, send a symmetric * crypto-NAK packet. If restrict no-moblize, send a symmetric
* active packet instead. * active packet instead.
*/ */
case NEWPS: case NEWPS:
if (!AUTH(p->flags & P_NOTRUST, auth)) { if (!AUTH(p->flags & P_NOTRUST, auth)) {
if (auth == A_ERROR) if (auth == A_ERROR)
fast_xmit(r, M_SACT, A_CRYPTO); fast_xmit(r, M_SACT, A_CRYPTO);
return; /* crypto-NAK packet sent */ return; /* crypto-NAK packet sent */
} }
skipping to change at page 85, line 36 skipping to change at page 87, line 36
A.5.5.1. clock_select() A.5.5.1. clock_select()
/* /*
* clock_select() - find the best clocks * clock_select() - find the best clocks
*/ */
void void
clock_select() { clock_select() {
struct p *p, *osys; /* peer structure pointers */ struct p *p, *osys; /* peer structure pointers */
double low, high; /* correctness interval extents */ double low, high; /* correctness interval extents */
int allow, found, chime; /* used by intersecion algorithm */ int allow, found, chime; /* used by intersection algorithm */
int n, i, j; int n, i, j;
/* /*
* We first cull the falsetickers from the server population, * We first cull the falsetickers from the server population,
* leaving only the truechimers. The correctness interval for * leaving only the truechimers. The correctness interval for
* association p is the interval from offset - root_dist() to * association p is the interval from offset - root_dist() to
* offset + root_dist(). The object of the game is to find a * offset + root_dist(). The object of the game is to find a
* majority clique; that is, an intersection of correctness * majority clique; that is, an intersection of correctness
* intervals numbering more than half the server population. * intervals numbering more than half the server population.
* *
skipping to change at page 99, line 44 skipping to change at page 101, line 44
void void
clock_adjust() { clock_adjust() {
double dtemp; double dtemp;
/* /*
* Update the process time c.t. Also increase the dispersion * Update the process time c.t. Also increase the dispersion
* since the last update. In contrast to NTPv3, NTPv4 does not * since the last update. In contrast to NTPv3, NTPv4 does not
* declare unsynchronized after one day, since the dispersion * declare unsynchronized after one day, since the dispersion
* threshold serves this function. When the dispersion exceeds * threshold serves this function. When the dispersion exceeds
* MAXDIST (1 s), the server is considered unfit for * MAXDIST (1 s), the server is considered unfit for
* synchroniztion. * synchronization.
*/ */
c.t++; c.t++;
s.rootdisp += PHI; s.rootdisp += PHI;
/* /*
* Implement the phase and frequency adjustments. The gain * Implement the phase and frequency adjustments. The gain
* factor (denominator) is not allowed to increase beyond the * factor (denominator) is not allowed to increase beyond the
* Allan intercept. It doesn't make sense to average phase noise * Allan intercept. It doesn't make sense to average phase noise
* beyond this point and it helps to damp residual offset at the * beyond this point and it helps to damp residual offset at the
* longer poll intervals. * longer poll intervals.
skipping to change at page 104, line 39 skipping to change at page 106, line 39
p->hpoll = max(min(MAXPOLL, poll), MINPOLL); p->hpoll = max(min(MAXPOLL, poll), MINPOLL);
if (p->burst > 0) { if (p->burst > 0) {
if (p->nextdate != c.t) if (p->nextdate != c.t)
return; return;
else else
p->nextdate += BTIME; p->nextdate += BTIME;
} else { } else {
/* /*
* While not shown here, the reference implementation * While not shown here, the reference implementation
* randonizes the poll interval by a small factor. * randomizes the poll interval by a small factor.
*/ */
p->nextdate = p->outdate + (1 << max(min(p->ppoll, p->nextdate = p->outdate + (1 << max(min(p->ppoll,
p->hpoll), MINPOLL)); p->hpoll), MINPOLL));
} }
/* /*
* It might happen that the due time has already passed. If so, * It might happen that the due time has already passed. If so,
* make it one second in the future. * make it one second in the future.
*/ */
if (p->nextdate <= c.t) if (p->nextdate <= c.t)
skipping to change at page 107, line 26 skipping to change at page 109, line 26
William Kasch (editor) William Kasch (editor)
The Johns Hopkins University Applied Physics Laboratory The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road 11100 Johns Hopkins Road
Laurel, MD 20723-6099 Laurel, MD 20723-6099
US US
Phone: +1 443 778 7463 Phone: +1 443 778 7463
Email: william.kasch@jhuapl.edu Email: william.kasch@jhuapl.edu
Jim Martin (editor) Jim Martin (editor)
The Daedelus Group Woven Systems
721 Alameda de las Pulgas 2455 Augustine Drive, Suite 211
Belmont, CA 94002 Santa Clara, CA 95054
US US
Phone: +1 408 799-2788 Phone: +1 408 654-8900 x131
Email: jim@daedelus.com Email: jim@wovensystems.com
Dr. David L. Mills Dr. David L. Mills
University of Delaware University of Delaware
Newark, DE 19716 Newark, DE 19716
US US
Phone: +1 302 831 8247 Phone: +1 302 831 8247
Email: mills@udel.edu Email: mills@udel.edu
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 108, line 44 skipping to change at line 4824
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 83 change blocks. 
176 lines changed or deleted 186 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/