draft-ietf-ntp-mode-6-cmds-00.txt   draft-ietf-ntp-mode-6-cmds-01.txt 
Network Working Group D. Mills Network Working Group D. Mills
Internet-Draft University of Deleware Internet-Draft University of Deleware
Intended status: Historic B. Haberman, Ed. Intended status: Informational B. Haberman, Ed.
Expires: October 20, 2017 JHU Expires: November 19, 2017 JHU
April 18, 2017 May 18, 2017
Control Messages Protocol for Use with Network Time Protocol Version 4 Control Messages Protocol for Use with Network Time Protocol Version 4
draft-ietf-ntp-mode-6-cmds-00 draft-ietf-ntp-mode-6-cmds-01
Abstract Abstract
This document describes the structure of the control messages used This document describes the structure of the control messages used
with the Network Time Protocol. These control messages can be used with the Network Time Protocol. These control messages can be used
to monitor and control the Network Time Protocol application running to monitor and control the Network Time Protocol application running
on any IP network attached computer. The information in this on any IP network attached computer. The information in this
document was originally described in Appendix B of RFC 1305. The document was originally described in Appendix B of RFC 1305. The
goal of this document is to provide a historic description of the goal of this document is to provide a historic description of the
control messages. control messages.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on October 20, 2017. This Internet-Draft will expire on November 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Control Message Overview . . . . . . . . . . . . . . . . 2 1.1. Control Message Overview . . . . . . . . . . . . . . . . 3
2. NTP Control Message Format . . . . . . . . . . . . . . . . . 4 2. NTP Control Message Format . . . . . . . . . . . . . . . . . 4
3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. System Status Word . . . . . . . . . . . . . . . . . . . 6 3.1. System Status Word . . . . . . . . . . . . . . . . . . . 8
3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 8 3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 10
3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 9 3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 12
3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 10 3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 12
4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . 14 8. Normative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
RFC 1305 [RFC1305] described a set of control messages for use within RFC 1305 [RFC1305] described a set of control messages for use within
the Network Time Protocol (NTP) when a comprehensive network the Network Time Protocol (NTP) when a comprehensive network
management solution was not available. The definitions of these management solution was not available. The definitions of these
control messages were not promulgated to RFC 5905 [RFC5905] when NTP control messages were not promulgated to RFC 5905 [RFC5905] when NTP
version 4 was documented. These messages were intended for use only version 4 was documented. These messages were intended for use only
in systems where no other management facilities were available or in systems where no other management facilities were available or
appropriate, such as in dedicated-function bus peripherals. Support appropriate, such as in dedicated-function bus peripherals. Support
skipping to change at page 4, line 19 skipping to change at page 5, line 8
2. NTP Control Message Format 2. NTP Control Message Format
The format of the NTP Control Message header, which immediately The format of the NTP Control Message header, which immediately
follows the UDP header, is shown in Figure 1. Following is a follows the UDP header, is shown in Figure 1. Following is a
description of its fields. Bit positions marked as zero are reserved description of its fields. Bit positions marked as zero are reserved
and should always be transmitted as zero. and should always be transmitted as zero.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| VN |Mode |R|E|M| OpCode | Sequence Number | |LI | VN |Mode |R|E|M| OpCode | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Association ID | | Status | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Count | | Offset | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Data (up to 468 bytes) / / Data (up to 468 bytes) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Authenticator (optional, 96 bytes) / / Authenticator (optional, 96 bytes) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NTP Control Message Header Figure 1: NTP Control Message Header
Version Number (VN): This is a three-bit integer indicating the NTP Leap Indicator (LI): This is a two-bit integer that is set to b00 for
version number, currently four (4). control message requests and responses. The Leap Indicator value
used as this position in mot NTP modes is in the System Status Word
provided in some control message responses.
Version Number (VN): This is a three-bit integer indicating a minimum
NTP version number. NTP servers do not respond to control messages
with an unrecognized version number. Requests may intentionally use
a lower version number to enable interoperability with earlier
versions of NTP. Responses carry the same version as the
corresponding request.
Mode: This is a three-bit integer indicating the mode. The value 6 Mode: This is a three-bit integer indicating the mode. The value 6
indicates an NTP control message. indicates an NTP control message.
Response Bit (R): Set to zero for commands, one for responses. Response Bit (R): Set to zero for commands, one for responses.
Error Bit (E): Set to zero for normal response, one for error Error Bit (E): Set to zero for normal response, one for error
response. response.
More Bit (M): Set to zero for last fragment, one for all others. More Bit (M): Set to zero for last fragment, one for all others.
skipping to change at page 5, line 16 skipping to change at page 6, line 16
| Code | Meaning | | Code | Meaning |
+-------+--------------------------------------------------+ +-------+--------------------------------------------------+
| 0 | reserved | | 0 | reserved |
| 1 | read status command/response | | 1 | read status command/response |
| 2 | read variables command/response | | 2 | read variables command/response |
| 3 | write variables command/response | | 3 | write variables command/response |
| 4 | read clock variables command/response | | 4 | read clock variables command/response |
| 5 | write clock variables command/response | | 5 | write clock variables command/response |
| 6 | set trap address/port command/response | | 6 | set trap address/port command/response |
| 7 | trap response | | 7 | trap response |
| 8-31 | reserved | | 8 | runtime configuration command/response |
| 9 | export configuration to file command/response |
| 10 | retrieve remote address stats command/response |
| 11 | retrieve ordered list command/response |
| 12 | request client-specific nonce command/response |
| 13-30 | reserved |
| 31 | unset trap address/port command/response |
+-------+--------------------------------------------------+ +-------+--------------------------------------------------+
Sequence Number: This is a 16-bit integer indicating the sequence Sequence Number: This is a 16-bit integer indicating the sequence
number of the command or response. number of the command or response. Each request uses a different
sequence number. Each response carries the same sequence number as
its corresponding request. For asynchronous trap responses, the
responder increments the sequence number by one for each response,
allowing trap receivers to detect missing trap responses. The
sequence number of each fragment of a multiple-datagram response
carries the same sequence number, copied from the request.
Status: This is a 16-bit code indicating the current status of the Status: This is a 16-bit code indicating the current status of the
system, peer or clock, with values coded as described in following system, peer or clock, with values coded as described in following
sections. sections.
Association ID: This is a 16-bit integer identifying a valid Association ID: This is a 16-bit unsigned integer identifying a valid
association. association, or zero for the system clock.
Offset: This is a 16-bit integer indicating the offset, in octets, of Offset: This is a 16-bit unsigned integer indicating the offset, in
the first octet in the data area. octets, of the first octet in the data area. The offset is set to
zero in requests. Responses spanning multiple datagrams use a
positive offset in all but the first datagram.
Count: This is a 16-bit integer indicating the length of the data Count: This is a 16-bit unsigned integer indicating the length of the
field, in octets. data field, in octets.
Data: This contains the message data for the command or response. Data: This contains the message data for the command or response.
The maximum number of data octets is 468. The maximum number of data octets is 468.
Padding (optional): Conains zero to three octets with value zero, as
needed to ensure the overall control message size is a multiple of 4
octets.
Authenticator (optional): When the NTP authentication mechanism is Authenticator (optional): When the NTP authentication mechanism is
implemented, this contains the authenticator information defined in implemented, this contains the authenticator information defined in
Appendix C of RFC 1305. Appendix C of RFC 1305.
3. Status Words 3. Status Words
Status words indicate the present status of the system, associations Status words indicate the present status of the system, associations
and clock. They are designed to be interpreted by network-monitoring and clock. They are designed to be interpreted by network-monitoring
programs and are in one of four 16-bit formats shown in Figure 2 and programs and are in one of four 16-bit formats shown in Figure 2 and
described in this section. System and peer status words are described in this section. System and peer status words are
skipping to change at page 6, line 30 skipping to change at page 8, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Clock Status | Code | | Clock Status | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Radio Status Word Radio Status Word
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Reserved | | Error Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Status Word Error Status Word
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Count | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Clock Status Word
Figure 2: Status Word Formats Figure 2: Status Word Formats
3.1. System Status Word 3.1. System Status Word
The system status word appears in the status field of the response to The system status word appears in the status field of the response to
a read status or read variables command with a zero association a read status or read variables command with a zero association
identifier. The format of the system status word is as follows: identifier. The format of the system status word is as follows:
Leap Indicator (LI): This is a two-bit code warning of an impending Leap Indicator (LI): This is a two-bit code warning of an impending
leap second to be inserted/deleted in the last minute of the current leap second to be inserted/deleted in the last minute of the current
day, with bit 0 and bit 1, respectively, coded as follows: day, with bit 0 and bit 1, respectively, coded as follows:
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| LI | Meaning | | LI | Meaning |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| 00 | no warning | | 00 | no warning |
| 01 | read status command/response | | 01 | insert second after 23:59:59 of the current day |
| 10 | read variables command/response | | 10 | delete second 23:59:59 of the current day |
| 11 | write variables command/response | | 11 | unsynchronized |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
Clock Source (Clock Src): This is a six-bit integer indicating the Clock Source (Clock Src): This is a six-bit integer indicating the
current synchronization source, with values coded as follows: current synchronization source, with values coded as follows:
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Code | Meaning | | Code | Meaning |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 0 | unspecified or unknown | | 0 | unspecified or unknown |
| 1 | Calibrated atomic clock (e.g.,, HP 5061) | | 1 | Calibrated atomic clock (e.g., PPS, HP 5061) |
| 2 | VLF (band 4) or LF (band 5) radio (e.g.,, OMEGA,, WWVB) | | 2 | VLF (band 4) or LF (band 5) radio (e.g., OMEGA,, WWVB) |
| 3 | HF (band 7) radio (e.g.,, CHU,, MSF,, WWV/H) | | 3 | HF (band 7) radio (e.g., CHU, MSF, WWV/H) |
| 4 | UHF (band 9) satellite (e.g.,, GOES,, GPS) | | 4 | UHF (band 9) satellite (e.g., GOES, GPS) |
| 5 | local net (e.g.,, DCN,, TSP,, DTS) | | 5 | local net (e.g., DCN, TSP, DTS) |
| 6 | UDP/NTP | | 6 | UDP/NTP |
| 7 | UDP/TIME | | 7 | UDP/TIME |
| 8 | eyeball-and-wristwatch | | 8 | eyeball-and-wristwatch |
| 9 | telephone modem (e.g.,, NIST) | | 9 | telephone modem (e.g., NIST) |
| 10-63 | reserved | | 10-63 | reserved |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
System Event Counter (Count): This is a four-bit integer indicating System Event Counter (Count): This is a four-bit integer indicating
the number of system exception events occurring since the last time the number of system events occurring since the last time the System
the system status word was returned in a response or included in a Event Code changed. Upon reaching 15, subsequent events with the
trap message. The counter is cleared when returned in the status same code are not counted.
field of a response and freezes when it reaches the value 15.
System Event Code (Code): This is a four-bit integer identifying the System Event Code (Code): This is a four-bit integer identifying the
latest system exception event, with new values overwriting previous latest system exception event, with new values overwriting previous
values, and coded as follows: values, and coded as follows:
+------+-----------------------------------------------------------+ +------+---------------------------------------------------------+
| Code | Meaning | | Code | Meaning |
+------+-----------------------------------------------------------+ +------+---------------------------------------------------------+
| 0 | unspecified | | 0 | unspecified |
| 1 | system restart | | 1 | frequency correction (drift) file not available |
| 2 | system or hardware fault | | 2 | frequency correction started (frequency stepped) |
| 3 | system new status word (leap bits or | | 3 | spike detected and ignored, starting stepout timer |
| | synchronization change) | | 4 | frequency training started |
| 4 | system new synchronization source or stratum (sys.peer or | | 5 | clock synchronized |
| | sys.stratum change) | | 6 | system restart |
| 5 | system clock reset (offset correction exceeds CLOCK.MAX) | | 7 | panic stop (required step greater than panic threshold) |
| 6 | system invalid time or date (see NTP specification) | | 8 | no system peer |
| 7 | system clock exception (see system clock status word) | | 9 | leap second insertion/deletion armed for the |
| 8-15 | reserved | | | of the current month |
+------+-----------------------------------------------------------+ | 10 | leap second disarmed |
| 11 | leap second inserted or deleted |
| 12 | clock stepped (stepout timer expired) |
| 13 | kernel loop discipline status changed |
| 14 | leapseconds table loaded from file |
| 15 | leapseconds table outdated, updated file needed |
+------+---------------------------------------------------------+
3.2. Peer Status Word 3.2. Peer Status Word
A peer status word is returned in the status field of a response to a A peer status word is returned in the status field of a response to a
read status, read variables or write variables command and appears read status, read variables or write variables command and appears
also in the list of association identifiers and status words returned also in the list of association identifiers and status words returned
by a read status command with a zero association identifier. The by a read status command with a zero association identifier. The
format of a peer status word is as follows: format of a peer status word is as follows:
Peer Status (Status): This is a five-bit code indicating the status Peer Status (Status): This is a five-bit code indicating the status
of the peer determined by the packet procedure, with bits assigned as of the peer determined by the packet procedure, with bits assigned as
follows: follows:
+-------------+---------------------------------------------------+ +-------------+---------------------------------------------------+
| Peer Status | Meaning | | Peer Status | Meaning |
+-------------+---------------------------------------------------+ +-------------+---------------------------------------------------+
| 0 | configured (peer.config) | | 0 | configured (peer.config) |
| 1 | authentication enabled (peer.authenable) | | 1 | authentication enabled (peer.authenable) |
| 2 | authentication okay (peer.authentic) | | 2 | authentication okay (peer.authentic) |
| 3 | reachability okay (peer.reach <F128M>?F255D> 0) | | 3 | reachability okay (peer.reach != 0) |
| 4 | reserved | | 4 | broadcast association |
+-------------+---------------------------------------------------+ +-------------+---------------------------------------------------+
Peer Selection (SEL): This is a three-bit integer indicating the Peer Selection (SEL): This is a three-bit integer indicating the
status of the peer determined by the clock-selection procedure, with status of the peer determined by the clock-selection procedure, with
values coded as follows: values coded as follows:
+-----+-------------------------------------------------------------+ +-----+-------------------------------------------------------------+
| Sel | Meaning | | Sel | Meaning |
+-----+-------------------------------------------------------------+ +-----+-------------------------------------------------------------+
| 0 | rejected | | 0 | rejected |
| 1 | passed receive sanity checks | | 1 | discarded by intersection algorithm |
| 2 | passed correctness check (intersection algorithm | | 2 | discarded bu table overflow (not currently used) |
| 3 | passed candidate checks (if limit check implemented) | | 3 | discarded by the cluster algorithm |
| 4 | passed outlyer checks (cluster algorithm | | 4 | included by the combine algorithm |
| 5 | current synchronization source; max distance exceeded | | 5 | backup source (with more than sys.maxclock survivors) |
| | (if limit check implemented) | | 6 | system peer (synchronization source) |
| 6 | current synchronization source; max distance okay | | 7 | PPS (pulse per second) peer |
| 7 | reserved |
+-----+-------------------------------------------------------------+ +-----+-------------------------------------------------------------+
Peer Event Counter (Count): This is a four-bit integer indicating the Peer Event Counter (Count): This is a four-bit integer indicating the
number of peer exception events that occurred since the last time the number of peer exception events that occurred since the last time the
peer status word was returned in a response or included in a trap peer event code changed. Upon reaching 15, subsequent events with
message. The counter is cleared when returned in the status field of the same code are not counted.
a response and freezes when it reaches the value 15.
Peer Event Code (Code): This is a four-bit integer identifying the Peer Event Code (Code): This is a four-bit integer identifying the
latest peer exception event, with new values overwriting previous latest peer exception event, with new values overwriting previous
values, and coded as follows: values, and coded as follows:
+-------+---------------------------------------------------------+ +-------+--------------------------------------------------------+
| Peer | | | Peer | |
| Event | Meaning | | Event | Meaning |
| Code | | | Code | |
+-------+---------------------------------------------------------+ +-------+--------------------------------------------------------+
| 0 | unspecified | | 0 | unspecified |
| 1 | peer IP error | | 1 | association mobilized |
| 2 | peer authentication failure (peer.authentic bit 1 --> 0 | | 2 | association demobilized |
| 3 | peer unreachable (peer.reach was nonzero now zero) | | 3 | peer unreachable (peer.reach was nonzero now zero) |
| 4 | peer reachable (peer.reach was zero now nonzero) | | 4 | peer reachable (peer.reach was zero now nonzero) |
| 5 | peer clock exception (see peer clock status word) | | 5 | association restarted or timed out |
| 6-15 | reserved | | 6 | no reply (only used with one-shot ntpd -q) |
+-------+---------------------------------------------------------+ | 7 | peer rate limit exceeded (kiss code RATE received) |
| 8 | access denied (kiss code DENY received) |
| 9 | leap second insertion/deletion at month's end armed |
| | by peer vote |
| 10 | became system peer (sys.peer) |
| 11 | reference clock event (see clock status word) |
| 12 | authentication failed |
| 13 | popcorn spike suppressed by peer clock filter register |
| 14 | entering interleaved mode |
| 15 | recovered from interleave error |
+-------+--------------------------------------------------------+
3.3. Clock Status Word 3.3. Clock Status Word
There are two ways a reference clock can be attached to a NTP service There are two ways a reference clock can be attached to a NTP service
host, as an dedicated device managed by the operating system and as a host, as an dedicated device managed by the operating system and as a
synthetic peer managed by NTP. As in the read status command, the synthetic peer managed by NTP. As in the read status command, the
association identifier is used to identify which one, zero for the association identifier is used to identify which one, zero for the
system clock and nonzero for a peer clock. Only one system clock is system clock and nonzero for a peer clock. Only one system clock is
supported by the protocol, although many peer clocks can be supported by the protocol, although many peer clocks can be
supported. A system or peer clock status word appears in the status supported. A system or peer clock status word appears in the status
field of the response to a read clock variables or write clock field of the response to a read clock variables or write clock
variables command. This word can be considered an extension of the variables command. This word can be considered an extension of the
system status word or the peer status word as appropriate. The system status word or the peer status word as appropriate. The
format of the clock status word is as follows: format of the clock status word is as follows:
Clock Status: This is an eight-bit integer indicating the current Reserved: An eight-bit integer that is ignored by requesters and
zeroed by responders.
Count: This is a four-bit integer indicating the number of clock
events that occurred since the last time the clock event code
changed. Upon reaching 15, subsequent events with the same code are
not counted.
Clock Code (Code): This is a four-bit integer indicating the current
clock status, with values coded as follows: clock status, with values coded as follows:
+--------------+--------------------------------------------------+ +--------------+--------------------------------------------------+
| Clock Status | Meaning | | Clock Status | Meaning |
+--------------+--------------------------------------------------+ +--------------+--------------------------------------------------+
| 0 | clock operating within nominals | | 0 | clock operating within nominals |
| 1 | reply timeout | | 1 | reply timeout |
| 2 | bad reply format | | 2 | bad reply format |
| 3 | hardware or software fault | | 3 | hardware or software fault |
| 4 | propagation failure | | 4 | propagation failure |
| 5 | bad date format or value | | 5 | bad date format or value |
| 6 | bad time format or value | | 6 | bad time format or value |
| 7-255 | reserved | | 7-15 | reserved |
+--------------+--------------------------------------------------+ +--------------+--------------------------------------------------+
Clock Event Code (Code): This is an eight-bit integer identifying the
latest clock exception event, with new values overwriting previous
values. When a change to any nonzero value occurs in the radio
status field, the radio status field is copied to the clock event
code field and a system or peer clock exception event is declared as
appropriate.
3.4. Error Status Word 3.4. Error Status Word
An error status word is returned in the status field of an error An error status word is returned in the status field of an error
response as the result of invalid message format or contents. Its response as the result of invalid message format or contents. Its
presence is indicated when the E (error) bit is set along with the presence is indicated when the E (error) bit is set along with the
response (R) bit in the response. It consists of an eight-bit response (R) bit in the response. It consists of an eight-bit
integer coded as follows: integer coded as follows:
+--------------+--------------------------------------------------+ +--------------+--------------------------------------------------+
| Error Status | Meaning | | Error Status | Meaning |
skipping to change at page 12, line 34 skipping to change at page 15, line 19
exception event occurs. The opcode field is 7 and the R bit is set. exception event occurs. The opcode field is 7 and the R bit is set.
The trap counter is incremented by one for each trap sent and the The trap counter is incremented by one for each trap sent and the
sequence field set to that value. The trap message is sent using the sequence field set to that value. The trap message is sent using the
IP address and port fields established by the set trap address/port IP address and port fields established by the set trap address/port
command. If a system trap the association identifier field is set to command. If a system trap the association identifier field is set to
zero and the status field contains the system status word. If a peer zero and the status field contains the system status word. If a peer
trap the association identifier field is set to that peer and the trap the association identifier field is set to that peer and the
status field contains the peer status word. Optional ASCII-coded status field contains the peer status word. Optional ASCII-coded
information can be included in the data field. information can be included in the data field.
Configure (8): The command data is parsed and applied as if supplied
in the daemon configuration file. The reference implementation
daemon requires authentication for this command.
Save Configuration (9): Write a snapshot of the current configuration
to the file name supplied as the command data. The reference
implementation daemon requires authentication for this command.
Further, the command is refused unless a directory in which to store
the resulting files has been explicitly configured by the operator.
Read MRU (10): Retrieves records of recently seen remote addresses
and associated statistics. Command data consists of name=value pairs
controlling the selection of records, as well as a requestor-specific
nonce previously retrieved using this command or opcode 12, Request
Nonce. The response consists of name=value pairs where some names
can appear multiple times using a dot followed by a zero-based index
to distinguish them, and to associate elements of the same record
with the same index. A new nonce is provided with each successful
response.
Read ordered list (11): Retrieves an ordered list. If the command
data is empty or the seven characters "ifstats" the associated
statistics, status and counters for each local address are returned.
If the command data is the characters "addr_restrictions" then the
set of IPv4 remote address restrictions followed by the set of IPv6
remote address restrictions (access control lists) are returned.
Other command data returns error code 5 (unknown variable name).
Similar to Read MRU, response information uses zero-based indexes as
part of the variable name preceding the equals sign and value, where
each index relates information for a single address or network. This
opcode requires authentication.
Request Nonce (12): Retrieves a 96-bit nonce specific to the
requesting remote address, which is valid for a limited period.
Command data is not used in the request. The nonce consists of a
64-bit NTP timestamp and 32 bits of hash derived from that timestamp,
the remote address, and salt known only to the server which varies
between daemon runs. The reference implementation honors nonces
which were issued less than 16 seconds prior. Regurgitation of the
nonce by a managment agent demonstrates to the server that the agent
can receive datagrams sent to the source address of the request,
making source address "spoofing" more difficult in a similar way as
TCP's three-way handshake.
Unset Trap (31): Removes the requesting remote address and port from
the list of trap receivers. Command data is not used in the request.
If the address and port are not in the list of trap receivers, the
error code is 4, bad association.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
6. Security Considerations 6. Security Considerations
A number of security vulnerabilities have been identified with these A number of security vulnerabilities have been identified with these
skipping to change at page 14, line 34 skipping to change at page 18, line 22
NTP and can help administrators make informed decisions on security NTP and can help administrators make informed decisions on security
measures to protect NTP devices from harmful queries and likely make measures to protect NTP devices from harmful queries and likely make
those systems less vulnerable. those systems less vulnerable.
7. Acknowledgements 7. Acknowledgements
Tim Plunkett created the original version of this document. Aanchal Tim Plunkett created the original version of this document. Aanchal
Malhotra provided the initial version of the Security Considerations Malhotra provided the initial version of the Security Considerations
section. section.
Karen O'Donoghue, David Hart, Harlan Stenn, and Philip Chimento
deserve credit for portions of this document due to their earlier
efforts to document these commands.
8. Normative References 8. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305, Specification, Implementation and Analysis", RFC 1305,
DOI 10.17487/RFC1305, March 1992, DOI 10.17487/RFC1305, March 1992,
<http://www.rfc-editor.org/info/rfc1305>. <http://www.rfc-editor.org/info/rfc1305>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
 End of changes. 30 change blocks. 
91 lines changed or deleted 204 lines changed or added

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