< 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 17 ¶		skipping to change at page 18, line 4 ¶
	control queries. However, sometimes the nosts do not want to block		control queries. However, sometimes the nosts do not want to block
	all queries and want to give access for certain control queries		all queries and want to give access for certain control queries
	remotely. This could be for the purpose of remote management and		remotely. This could be for the purpose of remote management and
	configuration of the hosts in certain scenarios. Such hosts tend to		configuration of the hosts in certain scenarios. Such hosts tend to
	use firewalls or other middleboxes to blacklist certain queries		use firewalls or other middleboxes to blacklist certain queries
	within the network.		within the network.
	Recent work (reference needed) shows that significantly fewer hosts		Recent work (reference needed) shows that significantly fewer hosts
	respond to mode 7 monlist queries as compared to other control		respond to mode 7 monlist queries as compared to other control
	queries because it is a well-known and exploited control query.		queries because it is a well-known and exploited control query.
	These queries are likely blocked using blacklists on firewalls and		These queries are likely blocked using blacklists on firewalls and
	middleboxes rather than the no-query option on NTP hosts. The		middleboxes rather than the no-query option on NTP hosts. The
	remaining control queries that can be exploited likely remain out of		remaining control queries that can be exploited likely remain out of
	the blacklist because they are undocumented in the current NTP		the blacklist because they are undocumented in the current NTP
	specification [RFC5905].		specification [RFC5905].
	This document describes all of the mode 6 control queries allowed by		This document describes all of the mode 6 control queries allowed by
	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. 31 change blocks.
	91 lines changed or deleted		205 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/