rfc9327.original   rfc9327.txt 
Network Working Group B. Haberman, Ed. Internet Engineering Task Force (IETF) B. Haberman, Ed.
Internet-Draft JHU Request for Comments: 9327 JHU
Intended status: Historic February 2022 Category: Historic October 2022
Expires: 19 August 2022 ISSN: 2070-1721
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-11
Abstract Abstract
This document describes the structure of the control messages that This document describes the structure of the control messages that
were historically used with the Network Time Protocol before the were historically used with the Network Time Protocol (NTP) before
advent of more modern control and management approaches. These the advent of more modern control and management approaches. These
control messages have been used to monitor and control the Network control messages have been used to monitor and control the NTP
Time Protocol application running on any IP network attached application running on any IP network attached computer. The
computer. The information in this document was originally described information in this document was originally described in Appendix B
in Appendix B of RFC 1305. The goal of this document is to provide of RFC 1305. The goal of this document is to provide an updated
an updated description of the control messages described in RFC 1305 description of the control messages described in RFC 1305 in order to
in order to conform with the updated Network Time Protocol conform with the updated NTP specification documented in RFC 5905.
specification documented in RFC 5905.
The publication of this document is not meant to encourage the The publication of this document is not meant to encourage the
development and deployment of these control messages. This document development and deployment of these control messages. This document
is only providing a current reference for these control messages is only providing a current reference for these control messages
given the current status of RFC 1305. given the current status of RFC 1305.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for the historical record.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines a Historic Document for the Internet community.
and may be updated, replaced, or obsoleted by other documents at any This document is a product of the Internet Engineering Task Force
time. It is inappropriate to use Internet-Drafts as reference (IETF). It represents the consensus of the IETF community. It has
material or to cite them other than as "work in progress." received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 5 August 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9327.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Control Message Overview . . . . . . . . . . . . . . . . 3 1.1. Terminology
1.2. Remote Facility Message Overview . . . . . . . . . . . . 5 1.2. Control Message Overview
2. NTP Control Message Format . . . . . . . . . . . . . . . . . 5 1.3. Remote Facility Message Overview
3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 7 2. NTP Control Message Format
3.1. System Status Word . . . . . . . . . . . . . . . . . . . 8 3. Status Words
3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 10 3.1. System Status Word
3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 12 3.2. Peer Status Word
3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 12 3.3. Clock Status Word
4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Error Status Word
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4. Commands
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 7. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. NTP Remote Facility Message Format
Appendix A. NTP Remote Facility Message Format . . . . . . . . . 20 Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Contributors
Author's Address
1. Introduction 1. Introduction
RFC 1305 [RFC1305] described a set of control messages for use within [RFC1305] describes a set of control messages for use within the
the Network Time Protocol (NTP) when a comprehensive network Network Time Protocol (NTP) when a comprehensive network management
management solution was not available. The definitions of these solution was not available. The definitions of these control
control messages were not promulgated to RFC 5905 [RFC5905] when NTP messages were not promulgated to [RFC5905] when NTP version 4 was
version 4 was documented. These messages were intended for use only documented. These messages were intended for use only in systems
in systems where no other management facilities were available or where no other management facilities were available or appropriate,
appropriate, such as in dedicated-function bus peripherals. Support such as in dedicated-function bus peripherals. Support for these
for these messages is not required in order to conform to RFC 5905 messages is not required in order to conform to [RFC5905]. The
[RFC5905]. The control messages are described here as a current control messages are described here as a current reference for use
reference for use with an RFC 5905 implementation of NTP. with an implementation of NTP from RFC 5905.
The publication of this document is not meant to encourage the The publication of this document is not meant to encourage the
development and deployment of these control messages. This document development and deployment of these control messages. This document
is only providing a current reference for these control messages is only providing a current reference for these control messages
given the current status of RFC 1305. given the current status of RFC 1305.
1.1. Control Message Overview 1.1. Terminology
The NTP Mode 6 control messages are used by NTP management programs The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Control Message Overview
The NTP mode 6 control messages are used by NTP management programs
(e.g., ntpq) when a more robust network management facility (e.g., (e.g., ntpq) when a more robust network management facility (e.g.,
SNMP) is not available. These control messages provide rudimentary SNMP) is not available. These control messages provide rudimentary
control and monitoring functions to manage a running instance of an control and monitoring functions to manage a running instance of an
NTP server. These commands are not designed to be used for NTP server. These commands are not designed to be used for
communication between instances of running NTP servers. communication between instances of running NTP servers.
The NTP Control Message has the value 6 specified in the mode field The NTP control message has the value 6 specified in the mode field
of the first octet of the NTP header and is formatted as shown in of the first octet of the NTP header and is formatted as shown in
Figure 1. The format of the data field is specific to each command Figure 1. The format of the data field is specific to each command
or response; however, in most cases the format is designed to be or response; however, in most cases, the format is designed to be
constructed and viewed by humans and so is coded in free-form ASCII. constructed and viewed by humans and so is coded in free-form ASCII.
This facilitates the specification and implementation of simple This facilitates the specification and implementation of simple
management tools in the absence of fully evolved network-management management tools in the absence of fully evolved network-management
facilities. As in ordinary NTP messages, the authenticator field facilities. As in ordinary NTP messages, the authenticator field
follows the data field. If the authenticator is used the data field follows the data field. If the authenticator is used, the data field
is zero-padded to a 32-bit boundary, but the padding bits are not is zero-padded to a 32-bit boundary, but the padding bits are not
considered part of the data field and are not included in the field considered part of the data field and are not included in the field
count. count.
IP hosts are not required to reassemble datagrams over a certain size IP hosts are not required to reassemble datagrams over a certain size
(576 octets for IPv4 [RFC0791] and 1280 octets for IPv6 [RFC2460]); (576 octets for IPv4 [RFC0791] and 1280 octets for IPv6 [RFC8200]);
however, some commands or responses may involve more data than will however, some commands or responses may involve more data than will
fit into a single datagram. Accordingly, a simple reassembly feature fit into a single datagram. Accordingly, a simple reassembly feature
is included in which each octet of the message data is numbered is included in which each octet of the message data is numbered
starting with zero. As each fragment is transmitted the number of starting with zero. As each fragment is transmitted, the number of
its first octet is inserted in the offset field and the number of its first octet is inserted in the offset field and the number of
octets is inserted in the count field. The more-data (M) bit is set octets is inserted in the count field. The more-data (M) bit is set
in all fragments except the last. in all fragments except the last.
Most control functions involve sending a command and receiving a Most control functions involve sending a command and receiving a
response, perhaps involving several fragments. The sender chooses a response, perhaps involving several fragments. The sender chooses a
distinct, nonzero sequence number and sets the status field and "R" distinct, nonzero sequence number and sets the status field, "R" bit,
and "E" bits to zero. The responder interprets the opcode and and "E" bit to zero. The responder interprets the opcode and
additional information in the data field, updates the status field, additional information in the data field, updates the status field,
sets the "R" bit to one and returns the three 32-bit words of the sets the "R" bit to one and returns the three 32-bit words of the
header along with additional information in the data field. In case header along with additional information in the data field. In the
of invalid message format or contents the responder inserts a code in case of invalid message format or contents, the responder inserts a
the status field, sets the "R" and "E" bits to one and, optionally, code in the status field, sets the "R" and "E" bits to one and,
inserts a diagnostic message in the data field. optionally, inserts a diagnostic message in the data field.
Some commands read or write system variables (e.g., s.offset) and Some commands read or write system variables (e.g., s.offset) and
peer variables (e.g., p.stratum) for an association identified in the peer variables (e.g., p.stratum) for an association identified in the
command. Others read or write variables associated with a radio command. Others read or write variables associated with a radio
clock or other device directly connected to a source of primary clock or other device directly connected to a source of primary
synchronization information. To identify which type of variable and synchronization information. To identify which type of variable and
association the Association ID is used. System variables are association, the Association ID is used. System variables are
indicated by the identifier zero. As each association is mobilized a indicated by the identifier zero. As each association is mobilized a
unique, nonzero identifier is created for it. These identifiers are unique, nonzero identifier is created for it. These identifiers are
used in a cyclic fashion, so that the chance of using an old used in a cyclic fashion, so that the chance of using an old
identifier which matches a newly created association is remote. A identifier that matches a newly created association is remote. A
management entity can request a list of current identifiers and management entity can request a list of current identifiers and
subsequently use them to read and write variables for each subsequently use them to read and write variables for each
association. An attempt to use an expired identifier results in an association. An attempt to use an expired identifier results in an
exception response, following which the list can be requested again. exception response, following which the list can be requested again.
Some exception events, such as when a peer becomes reachable or Some exception events, such as when a peer becomes reachable or
unreachable, occur spontaneously and are not necessarily associated unreachable, occur spontaneously and are not necessarily associated
with a command. An implementation may elect to save the event with a command. An implementation may elect to save the event
information for later retrieval or to send an asynchronous response information for later retrieval, to send an asynchronous response
(called a trap) or both. In case of a trap the IP address and port (called a trap), or both. In case of a trap, the IP address and port
number is determined by a previous command and the sequence field is number are determined by a previous command and the sequence field is
set as described below. Current status and summary information for set as described below. Current status and summary information for
the latest exception event is returned in all normal responses. Bits the latest exception event is returned in all normal responses. Bits
in the status field indicate whether an exception has occurred since in the status field indicate whether an exception has occurred since
the last response and whether more than one exception has occurred. the last response and whether more than one exception has occurred.
Commands need not necessarily be sent by an NTP peer, so ordinary Commands need not necessarily be sent by an NTP peer, so ordinary
access-control procedures may not apply; however, the optional mask/ access-control procedures may not apply; however, the optional mask/
match mechanism suggested in Section Section 6 elsewhere in this match mechanism suggested in Section 6 provides the capability to
document provides the capability to control access by mode number, so control access by mode number, so this could be used to limit access
this could be used to limit access for control messages (mode 6) to for control messages (mode 6) to selected address ranges.
selected address ranges.
1.2. Remote Facility Message Overview 1.3. Remote Facility Message Overview
The original development of the NTP daemon included a remote facility The original development of the NTP daemon included a Remote Facility
for monitoring and configuration. This facility used mode 7 commands for monitoring and configuration. This facility used mode 7 commands
to communicate with the NTP daemon. This document illustrates the to communicate with the NTP daemon. This document illustrates the
mode 7 packet format only. The commands embedded in the mode 7 mode 7 packet format only. The commands embedded in the mode 7
messages are implementation specific and not standardized in any way. messages are implementation specific and not standardized in any way.
The mode 7 message format is described in Appendix A. The mode 7 message format is described in Appendix A.
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 the figure
description of its fields. is a description of its header fields.
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 |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) | | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Authenticator (optional, 20 or 24 bits) / / Authenticator (optional, 20 or 24 bits) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NTP Control Message Header Figure 1: NTP Control Message Header
Leap Indicator (LI): This is a two-bit integer that is set to b00 for Leap Indicator (LI):
control message requests and responses. The Leap Indicator value This is a 2-bit integer that is set to b00 for control message
used at this position in most NTP modes is in the System Status Word requests and responses. The Leap Indicator value used at this
provided in some control message responses. position in most 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 Version Number (VN):
NTP version number. NTP servers do not respond to control messages This is a 3-bit integer indicating a minimum NTP version number.
with an unrecognized version number. Requests may intentionally use NTP servers do not respond to control messages with an
a lower version number to enable interoperability with earlier unrecognized version number. Requests may intentionally use a
versions of NTP. Responses carry the same version as the lower version number to enable interoperability with earlier
corresponding request. 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:
indicates an NTP control message. This is a 3-bit integer indicating the mode. The value 6
indicates an NTP control message.
Response Bit (R): Set to zero for commands, one for responses. Response Bit (R):
Set to zero for commands; set to one for responses.
Error Bit (E): Set to zero for normal response, one for error Error Bit (E):
response. Set to zero for normal responses; set to one for an error
response.
More Bit (M): Set to zero for last fragment, one for all others. More Bit (M):
Set to zero for the last fragment; set to one for all others.
Operation Code (OpCode): This is a five-bit integer specifying the Operation Code (opcode):
command function. Values currently defined include the following: This is a 5-bit integer specifying the command function. Values
currently defined include the following:
+-------+--------------------------------------------------+ +=======+================================================+
| Code | Meaning | | Code | Meaning |
+-------+--------------------------------------------------+ +=======+================================================+
| 0 | reserved | | 0 | reserved |
| 1 | read status command/response | +-------+------------------------------------------------+
| 2 | read variables command/response | | 1 | read status command/response |
| 3 | write variables command/response | +-------+------------------------------------------------+
| 4 | read clock variables command/response | | 2 | read variables command/response |
| 5 | write clock variables command/response | +-------+------------------------------------------------+
| 6 | set trap address/port command/response | | 3 | write variables command/response |
| 7 | trap response | +-------+------------------------------------------------+
| 8 | runtime configuration command/response | | 4 | read clock variables command/response |
| 9 | export configuration to file command/response | +-------+------------------------------------------------+
| 10 | retrieve remote address stats command/response | | 5 | write clock variables command/response |
| 11 | retrieve ordered list command/response | +-------+------------------------------------------------+
| 12 | request client-specific nonce command/response | | 6 | set trap address/port command/response |
| 13-30 | reserved | +-------+------------------------------------------------+
| 31 | unset trap address/port command/response | | 7 | trap response |
+-------+--------------------------------------------------+ +-------+------------------------------------------------+
| 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 Table 1: Operation Codes
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 Sequence Number:
system, peer or clock, with values coded as described in following This is a 16-bit integer indicating the sequence number of the
sections. 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.
Association ID: This is a 16-bit unsigned integer identifying a valid Status:
association, or zero for the system clock. This is a 16-bit code indicating the current status of the system,
peer, or clock with values coded as described in following
sections.
Offset: This is a 16-bit unsigned integer indicating the offset, in Association ID:
octets, of the first octet in the data area. The offset is set to This is a 16-bit unsigned integer identifying a valid association
zero in requests. Responses spanning multiple datagrams use a or zero for the system clock.
positive offset in all but the first datagram.
Count: This is a 16-bit unsigned integer indicating the length of the Offset:
data field, in octets. This is a 16-bit unsigned integer indicating the offset, in
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.
Data: This contains the message data for the command or response. Count:
The maximum number of data octets is 468. This is a 16-bit unsigned integer indicating the length of the
data field, in octets.
Padding (optional): Contains zero to three octets with value zero, as Data:
needed to ensure the overall control message size is a multiple of 4 This contains the message data for the command or response. The
octets. maximum number of data octets is 468.
Authenticator (optional): When the NTP authentication mechanism is Padding (optional):
implemented, this contains the authenticator information defined in Contains zero to 3 octets with a value of zero, as needed to
Appendix C of [RFC1305]. ensure the overall control message size is a multiple of 4 octets.
Authenticator (optional):
When the NTP authentication mechanism is implemented, this
contains the authenticator information defined in Part Appendix C
of [RFC1305].
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
associated with responses for all commands except the read clock associated with responses for all commands except the read clock
variables, write clock variables and set trap address/port commands. variables, write clock variables, and set trap address/port commands.
The association identifier zero specifies the system status word, The association identifier zero specifies the system status word,
while a nonzero identifier specifies a particular peer association. while a nonzero identifier specifies a particular peer association.
The status word returned in response to read clock variables and The status word returned in response to read clock variables and
write clock variables commands indicates the state of the clock write clock variables commands indicates the state of the clock
hardware and decoding software. A special error status word is used hardware and decoding software. A special error status word is used
to report malformed command fields or invalid values. to report malformed command fields or invalid values.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 40 skipping to change at line 391
Clock Status Word 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):
leap second to be inserted/deleted in the last minute of the current This is a 2-bit code warning of an impending leap second to be
day, with bit 0 and bit 1, respectively, coded as follows: inserted/deleted in the last minute of the current day, with bit 0
and bit 1, respectively, coded as follows:
+====+=================================================+
| LI | Meaning |
+====+=================================================+
| 00 | no warning |
+----+-------------------------------------------------+
| 01 | insert second after 23:59:59 of the current day |
+----+-------------------------------------------------+
| 10 | delete second 23:59:59 of the current day |
+----+-------------------------------------------------+
| 11 | unsynchronized |
+----+-------------------------------------------------+
Table 2: Leap Indicator Codes
Clock Source (Clock Src):
This is a 6-bit integer indicating the current synchronization
source, with values coded as follows:
+=======+========================================================+
| Code | Meaning |
+=======+========================================================+
| 0 | unspecified or unknown |
+-------+--------------------------------------------------------+
| 1 | Calibrated atomic clock (e.g., PPS, HP 5061) |
+-------+--------------------------------------------------------+
| 2 | VLF (band 4) or LF (band 5) radio (e.g., OMEGA,, WWVB) |
+-------+--------------------------------------------------------+
| 3 | HF (band 7) radio (e.g., CHU, MSF, WWV/H) |
+-------+--------------------------------------------------------+
| 4 | UHF (band 9) satellite (e.g., GOES, GPS) |
+-------+--------------------------------------------------------+
| 5 | local net (e.g., DCN, TSP, DTS) |
+-------+--------------------------------------------------------+
| 6 | UDP/NTP |
+-------+--------------------------------------------------------+
| 7 | UDP/TIME |
+-------+--------------------------------------------------------+
| 8 | eyeball-and-wristwatch |
+-------+--------------------------------------------------------+
| 9 | telephone modem (e.g., NIST) |
+-------+--------------------------------------------------------+
| 10-63 | reserved |
+-------+--------------------------------------------------------+
Table 3: Clock Source Values
System Event Counter (Count):
This is a 4-bit integer indicating the number of system events
occurring since the last time the System Event Code changed. Upon
reaching 15, subsequent events with the same code are not counted.
System Event Code (Code):
This is a 4-bit integer identifying the latest system exception
event, with new values overwriting previous values, and coded as
follows:
+======+============================================================+
| Code | Meaning |
+======+============================================================+
| 0 | unspecified |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| LI | Meaning | | 1 | frequency correction (drift) file not available |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| 00 | no warning | | 2 | frequency correction started (frequency stepped) |
| 01 | insert second after 23:59:59 of the current day | +------+------------------------------------------------------------+
| 10 | delete second 23:59:59 of the current day | | 3 | spike detected and ignored, starting stepout timer |
| 11 | unsynchronized | +------+------------------------------------------------------------+
| 4 | frequency training started |
+------+------------------------------------------------------------+
| 5 | clock synchronized |
+------+------------------------------------------------------------+
| 6 | system restart |
+------+------------------------------------------------------------+
| 7 | panic stop (required step greater than panic threshold) |
+------+------------------------------------------------------------+
| 8 | no system peer |
+------+------------------------------------------------------------+
| 9 | leap second insertion/deletion armed for 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 |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
Clock Source (Clock Src): This is a six-bit integer indicating the
current synchronization source, with values coded as follows:
+-------+-----------------------------------------------------------+ Table 4: System Event Codes
| Code | Meaning |
+-------+-----------------------------------------------------------+
| 0 | unspecified or unknown |
| 1 | Calibrated atomic clock (e.g., PPS, HP 5061) |
| 2 | VLF (band 4) or LF (band 5) radio (e.g., OMEGA,, WWVB) |
| 3 | HF (band 7) radio (e.g., CHU, MSF, WWV/H) |
| 4 | UHF (band 9) satellite (e.g., GOES, GPS) |
| 5 | local net (e.g., DCN, TSP, DTS) |
| 6 | UDP/NTP |
| 7 | UDP/TIME |
| 8 | eyeball-and-wristwatch |
| 9 | telephone modem (e.g., NIST) |
| 10-63 | reserved |
+-------+-----------------------------------------------------------+
System Event Counter (Count): This is a four-bit integer indicating 3.2. Peer Status Word
the number of system events occurring since the last time the System
Event Code changed. Upon reaching 15, subsequent events with the
same code are not counted.
System Event Code (Code): This is a four-bit integer identifying the A peer status word is returned in the status field of a response to a
latest system exception event, with new values overwriting previous read status, read variables, or write variables command and appears
values, and coded as follows: in the list of Association IDs and status words returned by a read
status command with a zero Association ID. The format of a peer
status word is as follows:
+------+---------------------------------------------------------+ Peer Status (Status):
| Code | Meaning | This is a 5-bit code indicating the status of the peer determined
+------+---------------------------------------------------------+ by the packet procedure, with bits assigned as follows:
| 0 | unspecified |
| 1 | frequency correction (drift) file not available |
| 2 | frequency correction started (frequency stepped) |
| 3 | spike detected and ignored, starting stepout timer |
| 4 | frequency training started |
| 5 | clock synchronized |
| 6 | system restart |
| 7 | panic stop (required step greater than panic threshold) |
| 8 | no system peer |
| 9 | leap second insertion/deletion armed for the |
| | 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 +=================+==========================================+
| Peer Status bit | Meaning |
+=================+==========================================+
| 0 | configured (peer.config) |
+-----------------+------------------------------------------+
| 1 | authentication enabled (peer.authenable) |
+-----------------+------------------------------------------+
| 2 | authentication okay (peer.authentic) |
+-----------------+------------------------------------------+
| 3 | reachability okay (peer.reach != 0) |
+-----------------+------------------------------------------+
| 4 | broadcast association |
+-----------------+------------------------------------------+
A peer status word is returned in the status field of a response to a Table 5: Peer Status Bits
read status, read variables or write variables command and appears
also in the list of association identifiers and status words returned
by a read status command with a zero association identifier. The
format of a peer status word is as follows:
Peer Status (Status): This is a five-bit code indicating the status Peer Selection (SEL):
of the peer determined by the packet procedure, with bits assigned as This is a 3-bit integer indicating the status of the peer
follows: determined by the clock-selection procedure, with values coded as
follows:
+-------------+---------------------------------------------------+ +=====+=======================================================+
| Peer Status | Meaning | | Sel | Meaning |
| bit | | +=====+=======================================================+
+-------------+---------------------------------------------------+ | 0 | rejected |
| 0 | configured (peer.config) | +-----+-------------------------------------------------------+
| 1 | authentication enabled (peer.authenable) | | 1 | discarded by intersection algorithm |
| 2 | authentication okay (peer.authentic) | +-----+-------------------------------------------------------+
| 3 | reachability okay (peer.reach != 0) | | 2 | discarded by table overflow (not currently used) |
| 4 | broadcast association | +-----+-------------------------------------------------------+
+-------------+---------------------------------------------------+ | 3 | discarded by the cluster algorithm |
+-----+-------------------------------------------------------+
| 4 | included by the combine algorithm |
+-----+-------------------------------------------------------+
| 5 | backup source (with more than sys.maxclock survivors) |
+-----+-------------------------------------------------------+
| 6 | system peer (synchronization source) |
+-----+-------------------------------------------------------+
| 7 | PPS (pulse per second) peer |
+-----+-------------------------------------------------------+
Peer Selection (SEL): This is a three-bit integer indicating the Table 6: Peer Selection Values
status of the peer determined by the clock-selection procedure, with
values coded as follows:
+-----+-------------------------------------------------------------+ Peer Event Counter (Count):
| Sel | Meaning | This is a 4-bit integer indicating the number of peer exception
+-----+-------------------------------------------------------------+ events that occurred since the last time the peer event code
| 0 | rejected | changed. Upon reaching 15, subsequent events with the same code
| 1 | discarded by intersection algorithm | are not counted.
| 2 | discarded by table overflow (not currently used) |
| 3 | discarded by the cluster algorithm |
| 4 | included by the combine algorithm |
| 5 | backup source (with more than sys.maxclock survivors) |
| 6 | system peer (synchronization source) |
| 7 | PPS (pulse per second) peer |
+-----+-------------------------------------------------------------+
Peer Event Counter (Count): This is a four-bit integer indicating the Peer Event Code (Code):
number of peer exception events that occurred since the last time the This is a 4-bit integer identifying the latest peer exception
peer event code changed. Upon reaching 15, subsequent events with event, with new values overwriting previous values, and coded as
the same code are not counted. follows:
Peer Event Code (Code): This is a four-bit integer identifying the +=================+===================================+
latest peer exception event, with new values overwriting previous | Peer Event Code | Meaning |
values, and coded as follows: +=================+===================================+
| 0 | unspecified |
+-----------------+-----------------------------------+
| 1 | association mobilized |
+-----------------+-----------------------------------+
| 2 | association demobilized |
+-----------------+-----------------------------------+
| 3 | peer unreachable (peer.reach was |
| | nonzero now zero) |
+-----------------+-----------------------------------+
| 4 | peer reachable (peer.reach was |
| | zero now nonzero) |
+-----------------+-----------------------------------+
| 5 | association restarted or timed |
| | out |
+-----------------+-----------------------------------+
| 6 | no reply (only used with one-shot |
| | clock set command) |
+-----------------+-----------------------------------+
| 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 |
+-----------------+-----------------------------------+
+-------+--------------------------------------------------------+ Table 7: Peer Event Code Values
| Peer | |
| Event | Meaning |
| Code | |
+-------+--------------------------------------------------------+
| 0 | unspecified |
| 1 | association mobilized |
| 2 | association demobilized |
| 3 | peer unreachable (peer.reach was nonzero now zero) |
| 4 | peer reachable (peer.reach was zero now nonzero) |
| 5 | association restarted or timed out |
| 6 | no reply (only used with one-shot clock set command) |
| 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 an NTP
host, as a dedicated device managed by the operating system and as a service host: as a dedicated device managed by the operating system
synthetic peer managed by NTP. As in the read status command, the and as a synthetic peer managed by NTP. As in the read status
association identifier is used to identify which one, zero for the command, the Association ID is used to identify the correct variable
system clock and nonzero for a peer clock. Only one system clock is for each clock: zero for the system clock and nonzero for a peer
supported by the protocol, although many peer clocks can be clock. Only one system clock is supported by the protocol, although
supported. A system or peer clock status word appears in the status many peer clocks can be supported. A system or peer clock status
field of the response to a read clock variables or write clock word appears in the status field of the response to a read clock
variables command. This word can be considered an extension of the variables or write clock variables command. This word can be
system status word or the peer status word as appropriate. The considered to be an extension of the system status word or the peer
format of the clock status word is as follows: status word as appropriate. The format of the clock status word is
as follows:
Reserved: An eight-bit integer that is ignored by requesters and Reserved:
zeroed by responders. This is an 8-bit integer that is ignored by requesters and zeroed
by responders.
Count: This is a four-bit integer indicating the number of clock Count:
events that occurred since the last time the clock event code This is a 4-bit integer indicating the number of clock events that
changed. Upon reaching 15, subsequent events with the same code are occurred since the last time the clock event code changed. Upon
not counted. reaching 15, subsequent events with the same code are not counted.
Clock Code (Code): This is a four-bit integer indicating the current Clock Code (Code):
clock status, with values coded as follows: This is a 4-bit integer indicating the current 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 | +--------------+---------------------------------+
| 2 | bad reply format | | 1 | reply timeout |
| 3 | hardware or software fault | +--------------+---------------------------------+
| 4 | propagation failure | | 2 | bad reply format |
| 5 | bad date format or value | +--------------+---------------------------------+
| 6 | bad time format or value | | 3 | hardware or software fault |
| 7-15 | reserved | +--------------+---------------------------------+
+--------------+--------------------------------------------------+ | 4 | propagation failure |
+--------------+---------------------------------+
| 5 | bad date format or value |
+--------------+---------------------------------+
| 6 | bad time format or value |
+--------------+---------------------------------+
| 7-15 | reserved |
+--------------+---------------------------------+
Table 8: Clock Code Values
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 8-bit integer
integer coded as follows: coded as follows:
+--------------+--------------------------------------------------+ +==============+==================================+
| Error Status | Meaning | | Error Status | Meaning |
+--------------+--------------------------------------------------+ +==============+==================================+
| 0 | unspecified | | 0 | unspecified |
| 1 | authentication failure | +--------------+----------------------------------+
| 2 | invalid message length or format | | 1 | authentication failure |
| 3 | invalid opcode | +--------------+----------------------------------+
| 4 | unknown association identifier | | 2 | invalid message length or format |
| 5 | unknown variable name | +--------------+----------------------------------+
| 6 | invalid variable value | | 3 | invalid opcode |
| 7 | administratively prohibited | +--------------+----------------------------------+
| 8-255 | reserved | | 4 | unknown Association ID |
+--------------+--------------------------------------------------+ +--------------+----------------------------------+
| 5 | unknown variable name |
+--------------+----------------------------------+
| 6 | invalid variable value |
+--------------+----------------------------------+
| 7 | administratively prohibited |
+--------------+----------------------------------+
| 8-255 | reserved |
+--------------+----------------------------------+
Table 9: Error Status Word Codes
4. Commands 4. Commands
Commands consist of the header and optional data field shown in Commands consist of the header and optional data field shown in
Figure 1. When present, the data field contains a list of Figure 1. When present, the data field contains a list of
identifiers or assignments in the form identifiers or assignments in the form
<<identifier>>[=<<value>>],<<identifier>>[=<<value>>],... where <<identifier>>[=<<value>>],<<identifier>>[=<<value>>],... where
<<identifier>> is the ASCII name of a system or peer variable such as <<identifier>> is the ASCII name of a system or peer variable such as
the ones specified in RFC 5905 and <<value>> is expressed as a the ones specified in RFC 5905 and <<value>> is expressed as a
decimal, hexadecimal or string constant in the syntax of the C decimal, hexadecimal, or string constant in the syntax of the C
programming language. Where no ambiguity exists, the "sys." or programming language. Where no ambiguity exists, the "sys." or
"peer." prefixes can be suppressed. Whitespace (ASCII nonprinting "peer." prefixes can be suppressed. Space characters (ASCII
format effectors) can be added to improve readability for simple nonprinting format effectors) can be added to improve readability for
monitoring programs that do not reformat the data field. Internet simple monitoring programs that do not reformat the data field.
addresses are represented as follows: IPv4 addresses are written in Representations of note are as follows:
the form [n.n.n.n], where n is in decimal notation and the brackets
are optional; IPv6 addresses are formulated based on the guidelines * IPv4 internet addresses are written in the form [n.n.n.n], where n
defined in [RFC5952]. Timestamps, including reference, originate, is in decimal notation and the brackets are optional
receive and transmit values, as well as the logical clock, are
represented in units of seconds and fractions, preferably in * IPv6 internet addresses are formulated based on the guidelines
hexadecimal notation. Delay, offset, dispersion and distance values defined in [RFC5952].
are represented in units of milliseconds and fractions, preferably in
decimal notation. All other values are represented as-is, preferably * Timestamps (including reference, originate, receive, and transmit
in decimal notation. values) and the logical clock are represented in units of seconds
and fractions, preferably in hexadecimal notation.
* Delay, offset, dispersion, and distance values are represented in
units of milliseconds and fractions, preferably in decimal
notation.
* All other values are represented as is, preferably in decimal
notation.
Implementations may define variables other than those described in Implementations may define variables other than those described in
RFC 5905. Called extramural variables, these are distinguished by RFC 5905; called "extramural variables", these are distinguished by
the inclusion of some character type other than alphanumeric or "." the inclusion of some character type other than alphanumeric or "."
in the name. For those commands that return a list of assignments in in the name. For those commands that return a list of assignments in
the response data field, if the command data field is empty, it is the response data field, if the command data field is empty, it is
expected that all available variables defined in RFC 5905 will be expected that all available variables defined in RFC 5905 will be
included in the response. For the read commands, if the command data included in the response. For the read commands, if the command data
field is nonempty, an implementation may choose to process this field field is nonempty, an implementation may choose to process this field
to individually select which variables are to be returned. to individually select which variables are to be returned.
Commands are interpreted as follows: Commands are interpreted as follows:
Read Status (1): The command data field is empty or contains a list Read Status (1):
of identifiers separated by commas. The command operates in two ways The command data field is empty or contains a list of identifiers
depending on the value of the association identifier. If this separated by commas. The command operates in two ways depending
identifier is nonzero, the response includes the peer identifier and on the value of the Association ID. If this identifier is
status word. Optionally, the response data field may contain other nonzero, the response includes the peer identifier and status
information, such as described in the Read Variables command. If the word. Optionally, the response data field may contain other
association identifier is zero, the response includes the system information, such as described in the Read Variables command. If
identifier (0) and status word, while the data field contains a list the association identifier is zero, the response includes the
of binary-coded pairs <<association identifier>> <<status word>>, one system identifier (0) and status word; the data field contains a
for each currently defined association. list of binary-coded pairs <<Association ID>> <<status word>>, one
for each currently defined association.
Read Variables (2): The command data field is empty or contains a Read Variables (2):
list of identifiers separated by commas. If the association The command data field is empty or contains a list of identifiers
identifier is nonzero, the response includes the requested peer separated by commas. If the Association ID is nonzero, the
identifier and status word, while the data field contains a list of response includes the requested peer identifier and status word;
peer variables and values as described above. If the association the data field contains a list of peer variables and values as
identifier is zero, the data field contains a list of system described above. If the Association ID is zero, the data field
variables. If a peer has been selected as the synchronization contains a list of system variables. If a peer has been selected
source, the response includes the peer identifier and status word; as the synchronization source, the response includes the peer
otherwise, the response includes the system identifier (0) and status identifier and status word; otherwise, the response includes the
word. system identifier (0) and status word.
Write Variables (3): The command data field contains a list of Write Variables (3):
assignments as described above. The variables are updated as The command data field contains a list of assignments as described
indicated. The response is as described for the Read Variables above. The variables are updated as indicated. The response is
command. as described for the Read Variables command.
Read Clock Variables (4): The command data field is empty or contains Read Clock Variables (4):
a list of identifiers separated by commas. The association The command data field is empty or contains a list of identifiers
identifier selects the system clock variables or peer clock variables separated by commas. The Association ID selects the system clock
in the same way as in the Read Variables command. The response variables or peer clock variables in the same way as in the Read
includes the requested clock identifier and status word and the data Variables command. The response includes the requested clock
field contains a list of clock variables and values, including the identifier and status word; the data field contains a list of
last timecode message received from the clock. clock variables and values, including the last timecode message
received from the clock.
Write Clock Variables (5): The command data field contains a list of Write Clock Variables (5):
assignments as described above. The clock variables are updated as The command data field contains a list of assignments as described
indicated. The response is as described for the Read Clock Variables above. The clock variables are updated as indicated. The
command. response is as described for the read clock variables command.
Set Trap Address/Port (6): The command association identifier, status Set Trap Address/Port (6):
and data fields are ignored. The address and port number for The command Association ID, status, and data fields are ignored.
subsequent trap messages are taken from the source address and port The address and port number for subsequent trap messages are taken
of the control message itself. The initial trap counter for trap from the source address and port of the control message itself.
response messages is taken from the sequence field of the command. The initial trap counter for trap response messages is taken from
The response association identifier, status and data fields are not the sequence field of the command. The response association
significant. Implementations should include sanity timeouts which identifier, status, and data fields are not significant.
prevent trap transmissions if the monitoring program does not renew Implementations should include logical timeouts that prevent trap
this information after a lengthy interval. transmissions if the monitoring program does not renew this
information after a lengthy interval.
Trap Response (7): This message is sent when a system, peer or clock Trap Response (7):
exception event occurs. The opcode field is 7 and the R bit is set. This message is sent when a system, peer, or clock exception event
The trap counter is incremented by one for each trap sent and the occurs. The opcode field is 7 and the R bit is set. The trap
sequence field set to that value. The trap message is sent using the counter is incremented by one for each trap sent and the sequence
IP address and port fields established by the set trap address/port field set to that value. The trap message is sent using the IP
command. If a system trap the association identifier field is set to address and port fields established by the set trap address/port
zero and the status field contains the system status word. If a peer command. If a system trap, the Association ID field is set to
trap the association identifier field is set to that peer and the zero and the status field contains the system status word. If a
status field contains the peer status word. Optional ASCII-coded peer trap, the Association ID field is set to that peer and the
information can be included in the data field. status field contains the peer status word. Optional ASCII-coded
information can be included in the data field.
Configure (8): The command data is parsed and applied as if supplied Configure (8):
in the daemon configuration file. The command data is parsed and applied as if supplied in the
daemon configuration file.
Save Configuration (9): Write a snapshot of the current configuration Save Configuration (9):
to the file name supplied as the command data. Further, the command Writes a snapshot of the current configuration to the file name
is refused unless a directory in which to store the resulting files supplied as the command data. Further, the command is refused
has been explicitly configured by the operator. unless a directory in which to store the resulting files has been
explicitly configured by the operator.
Read Most Recently Used (MRU) list (10): Retrieves records of Read Most Recently Used (MRU) list (10):
recently seen remote addresses and associated statistics. This Retrieves records of recently seen remote addresses and associated
command supports all of the state variables defined in Section 9 of statistics. This command supports all of the state variables
[RFC5905]. Command data consists of name=value pairs controlling the defined in Section 9 of [RFC5905]. Command data consists of
selection of records, as well as a requestor-specific nonce name=value pairs controlling the selection of records, as well as
previously retrieved using this command or opcode 12, Request Nonce. a requestor-specific nonce previously retrieved using this command
The response consists of name=value pairs where some names can appear or opcode 12 (Request Nonce). The response consists of name=value
multiple times using a dot followed by a zero-based index to pairs where some names can appear multiple times using a dot
distinguish them, and to associate elements of the same record with followed by a zero-based index to distinguish them and to
the same index. A new nonce is provided with each successful associate elements of the same record with the same index. A new
response. nonce is provided with each successful response.
Read ordered list (11): Retrieves a list ordered by IP address (IPv4 Read ordered list (11):
information precedes IPv6 information). If the command data is empty Retrieves a list ordered by IP address (IPv4 information precedes
or the seven characters "ifstats", the associated statistics, status IPv6 information). If the command data is empty or is the seven
and counters for each local address are returned. If the command characters "ifstats", the associated statistics, status, and
data is the characters "addr_restrictions" then the set of IPv4 counters for each local address are returned. If the command data
remote address restrictions followed by the set of IPv6 remote is the characters "addr_restrictions", then the set of IPv4 remote
address restrictions (access control lists) are returned. Other address restrictions followed by the set of IPv6 remote address
command data returns error code 5 (unknown variable name). Similar restrictions (access control lists) are returned. Other command
to Read MRU, response information uses zero-based indexes as part of data returns error code 5 (unknown variable name). Similar to
the variable name preceding the equals sign and value, where each Read MRU, response information uses zero-based indexes as part of
index relates information for a single address or network. This the variable name preceding the equals sign and value, where each
opcode requires authentication. index relates information for a single address or network. This
opcode requires authentication.
Request Nonce (12): Retrieves a 96-bit nonce specific to the Request Nonce (12):
requesting remote address, which is valid for a limited period. Retrieves a 96-bit nonce specific to the requesting remote
Command data is not used in the request. The nonce consists of a address, which is valid for a limited period. Command data is not
64-bit NTP timestamp and 32 bits of hash derived from that timestamp, used in the request. The nonce consists of a 64-bit NTP timestamp
the remote address, and salt known only to the server which varies and 32 bits of hash derived from that timestamp, the remote
between daemon runs. Inclusion of the nonce by a management agent address, and salt known only to the server, which varies between
demonstrates to the server that the agent can receive datagrams sent daemon runs. Inclusion of the nonce by a management agent
to the source address of the request, making source address demonstrates to the server that the agent can receive datagrams
"spoofing" more difficult in a similar way as TCP's three-way sent to the source address of the request, making source address
handshake. "spoofing" more difficult in a similar way as TCP's three-way
handshake.
Unset Trap (31): Removes the requesting remote address and port from Unset Trap (31):
the list of trap receivers. Command data is not used in the request. Removes the requesting remote address and port from the list of
If the address and port are not in the list of trap receivers, the trap receivers. Command data is not used in the request. If the
error code is 4, bad association. 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 has no IANA actions.
Note to RFC Editor: this section may be removed on publication as an
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
control messages. control messages.
NTP's control query interface allows reading and writing of system, NTP's control query interface allows reading and writing of system,
peer, and clock variables remotely from arbitrary IP addresses using peer, and clock variables remotely from arbitrary IP addresses using
commands mentioned in Section 4. Traditionally, overwriting these commands mentioned in Section 4. Overwriting these variables, but
variables, but not reading them, requires authentication by default. not reading them, requires authentication by default. However, this
However, this document argues that an NTP host must authenticate all document argues that an NTP host must authenticate all control
control queries and not just ones that overwrite these variables. queries and not just ones that overwrite these variables.
Alternatively, the host can use an access control list to explicitly Alternatively, the host can use an access control list to explicitly
list IP addresses that are allowed to control query the clients. list IP addresses that are allowed to control query the clients.
These access controls are required for the following reasons: These access controls are required for the following reasons:
* NTP as a Distributed Denial-of-Service (DDoS) vector. NTP timing NTP as a Distributed Denial-of-Service (DDoS) vector:
query and response packets (modes 1-2, 3-4, 5) are usually short NTP timing query and response packets (modes 1-2, 3-4, and 5) are
in size. However, some NTP control queries generate a very long usually short in size. However, some NTP control queries generate
packet in response to a short query. As such, there is a history a very long packet in response to a short query. As such, there
of use of NTP's control queries, which exhibit such behavior, to is a history of use of NTP's control queries, which exhibit such
perform DDoS attacks. These off-path attacks exploit the large behavior, to perform DoS attacks. These off-path attacks exploit
size of NTP control queries to cause UDP-based amplification the large size of NTP control queries to cause UDP-based
attacks (e.g., mode 7 monlist command generates a very long packet amplification attacks (e.g., mode 7 monlist command generates a
in response to a small query [CVE-DOS]). These attacks only use very long packet in response to a small query [CVE-DOS]). These
NTP as a vector for DoS attacks on other protocols, but do not attacks only use NTP as a vector for DoS attacks on other
affect the time service on the NTP host itself. To limit the protocols, but do not affect the time service on the NTP host
sources of these malicious commands, NTP server operators are itself. To limit the sources of these malicious commands, NTP
recommended to deploy ingress filtering [RFC3704]. server operators are recommended to deploy ingress filtering
[RFC3704].
* Time-shifting attacks through information leakage/overwriting. Time-shifting attacks through information leakage/overwriting:
NTP hosts save important system and peer state variables. An off- NTP hosts save important system and peer state variables. An off-
path attacker who can read these variables remotely can leverage path attacker who can read these variables remotely can leverage
the information leaked by these control queries to perform time- the information leaked by these control queries to perform time-
shifting and DoS attacks on NTP clients. These attacks do affect shifting and DDoS attacks on NTP clients. These attacks do affect
time synchronization on the NTP hosts. For instance, time synchronization on the NTP hosts. For instance:
- In the client/server mode, the client stores its local time * In the client/server mode, the client stores its local time when
when it sends the query to the server in its xmt peer variable. it sends the query to the server in its xmt peer variable. This
This variable is used to perform TEST2 to non-cryptographically variable is used to perform TEST2 to non-cryptographically
authenticate the server, i.e., if the origin timestamp field in authenticate the server (i.e., if the origin timestamp field in
the corresponding server response packet matches the xmt peer the corresponding server response packet matches the xmt peer
variable, then the client accepts the packet. An off-path variable, then the client accepts the packet). An off-path
attacker, with the ability to read this variable can easily attacker with the ability to read this variable can easily spoof
spoof server response packets for the client, which will pass server response packets for the client, which will pass TEST2 and
TEST2, and can deny service or shift time on the NTP client. can deny service or shift time on the NTP client. The specific
The specific attack is described in [CVE-SPOOF]. attack is described in [CVE-SPOOF].
- The client also stores its local time when the server response * The client also stores its local time when the server response is
is received in its rec peer variable. This variable is used received in its rec peer variable. This variable is used for
for authentication in interleaved-pivot mode. An off-path authentication in interleaved-pivot mode. An off-path attacker
attacker with the ability to read this state variable can with the ability to read this state variable can easily shift time
easily shift time on the client by passing this test. This on the client by passing this test. This attack is described in
attack is described in [CVE-SHIFT]. [CVE-SHIFT].
* Fast-Scanning. NTP mode 6 control messages are usually small UDP Fast-Scanning:
packets. Fast-scanning tools like ZMap can be used to spray the NTP mode 6 control messages are usually small UDP packets. Fast-
entire (potentially reachable) Internet with these messages within scanning tools like ZMap can be used to spray the entire
hours to identify vulnerable hosts. To make things worse, these (potentially reachable) Internet with these messages within hours
attacks can be extremely low-rate, only requiring a control query to identify vulnerable hosts. To make things worse, these attacks
for reconnaissance and a spoofed response to shift time on can be extremely low-rate, only requiring a control query for
vulnerable clients. reconnaissance and a spoofed response to shift time on vulnerable
clients.
* The mode 6 and 7 messages are vulnerable to replay attacks The mode 6 and 7 messages are vulnerable to replay attacks
[CVE-Replay]. If an attacker observes mode 6/7 packets that [CVE-Replay]:
modify the configuration of the server in any way, the attacker If an attacker observes mode 6/7 packets that modify the
can apply the same change at any time later simply by sending the configuration of the server in any way, the attacker can apply the
packets to the server again. The use of the nonce (Request Nonce same change at any time later by simply sending the packets to the
command) provides limited protection against replay attacks. server again. The use of the nonce (Request Nonce command)
provides limited protection against replay attacks.
NTP best practices recommend configuring NTP with the no-query NTP best practices recommend configuring NTP with the no-query
parameter. The no-query parameter blocks access to all remote parameter. The no-query parameter blocks access to all remote
control queries. However, sometimes the hosts do not want to block control queries. However, sometimes the hosts 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.
skipping to change at page 18, line 21 skipping to change at line 946
exploited control query. These queries are likely blocked using exploited control query. These queries are likely blocked using
blacklists on firewalls and middleboxes rather than the no-query blacklists on firewalls and middleboxes rather than the no-query
option on NTP hosts. The remaining control queries that can be option on NTP hosts. The remaining control queries that can be
exploited likely remain out of the blacklist because they are exploited likely remain out of the blacklist because they are
undocumented in the current NTP specification [RFC5905]. undocumented in the current NTP 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. The use of the legacy mode 6 those systems less vulnerable. The use of the legacy mode 6
interface is NOT RECOMMENDED.Regardless of which mode 6 commands an interface is NOT RECOMMENDED. Regardless of which mode 6 commands an
administrator may elect to allow, remote access to this facility administrator may elect to allow, remote access to this facility
needs to be protected from unauthorized access (e.g., strict ACLs). needs to be protected from unauthorized access (e.g., strict Access
Additionally, the legacy interface for mode 6 commands SHOULD NOT be Control Lists (ACLs)). Additionally, the legacy interface for mode 6
utilized in new deployments or implementation of NTP. commands SHOULD NOT be utilized in new deployments or implementation
of NTP.
7. Contributors
Dr. David Mills specified the vast majority of the mode 6 commands
during the development of RFC 1305 [RFC1305] and deserves the credit
for their existence and use.
8. Acknowledgements
Tim Plunkett created the original version of this document. Aanchal
Malhotra provided the initial version of the Security Considerations
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.
Miroshav Lichvar, Ulrich Windl, Dieter Sibold, J Ignacio Alvarez-
Hamelin, and Alex Campbell provided valuable comments on various
versions of this document.
9. References 7. References
9.1. Normative References 7.1. 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,
<https://www.rfc-editor.org/info/rfc1305>. <https://www.rfc-editor.org/info/rfc1305>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>. 2004, <https://www.rfc-editor.org/info/rfc3704>.
[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,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
9.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[CVE-DOS] NIST National Vulnerability Database, "CVE-2013-5211, 7.2. Informative References
https://nvd.nist.gov/vuln/detail/CVE-2013-5211", 2 January
2014. [CVE-DOS] NIST National Vulnerability Database, "CVE-2013-5211
Detail", 2 January 2014,
<https://nvd.nist.gov/vuln/detail/CVE-2013-5211>.
[CVE-Replay] [CVE-Replay]
NIST National Vulnerability Database, "CVE-2015-8140, NIST National Vulnerability Database, "CVE-2015-8140
https://nvd.nist.gov/vuln/detail/CVE-2015-8140", 30 Detail", 30 January 2015,
January 2015. <https://nvd.nist.gov/vuln/detail/CVE-2015-8140>.
[CVE-SHIFT] [CVE-SHIFT]
NIST National Vulnerability Database, "CVE-2016-1548, NIST National Vulnerability Database, "CVE-2016-1548
https://nvd.nist.gov/vuln/detail/CVE-2016-1548", 6 January Detail", 6 January 2017,
2017. <https://nvd.nist.gov/vuln/detail/CVE-2016-1548>.
[CVE-SPOOF] [CVE-SPOOF]
NIST National Vulnerability Database, "CVE-2015-8139, NIST National Vulnerability Database, "CVE-2015-8139
https://nvd.nist.gov/vuln/detail/CVE-2015-8139", 30 Detail", 30 January 2017,
January 2017. <https://nvd.nist.gov/vuln/detail/CVE-2015-8139>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", STD 86, RFC 8200,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Appendix A. NTP Remote Facility Message Format Appendix A. NTP Remote Facility Message Format
The format of the NTP Remote Facility Message header, which The format of the NTP Remote Facility Message header, which
immediately follows the UDP header, is shown in Figure 3. Following immediately follows the UDP header, is shown in Figure 3. A
is a description of its fields. Bit positions marked as zero are description of its fields follows Figure 3. Bit positions marked as
reserved and should always be transmitted as zero. zero are reserved 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|M| VN |Mode |A| Sequence | Implementation| Req Code | |R|M| VN |Mode |A| Sequence | Implementation| Req Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Err | Count | MBZ | Size | | Err | Count | MBZ | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Data (up to 500 bytes) / / Data (up to 500 bytes) /
skipping to change at page 20, line 32 skipping to change at line 1042
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption KeyID (when A bit set) | | Encryption KeyID (when A bit set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Message Authentication Code (when A bit set) / / Message Authentication Code (when A bit set) /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NTP Remote Facility Message Header Figure 3: NTP Remote Facility Message Header
Response Bit (R) : Set to 0 if the packet is a request. Set to 1 if Response Bit (R):
the packet is a response. Set to 0 if the packet is a request. Set to 1 if the packet is a
response.
More Bit (M) : Set to 0 if this is the last packet in a response, More Bit (M):
otherwise set to 1 in responses requiring more than one packet. Set to 0 if this is the last packet in a response; otherwise, set
to 1 in responses requiring more than one packet.
Version Number (VN) : Set to the version number of the NTP daemon. Version Number (VN):
Set to the version number of the NTP daemon.
Mode : Set to 7 for Remote Facility messages. Mode:
Set to 7 for Remote Facility messages.
Authenticated Bit (A) : If set to 1, this packet contains Authenticated Bit (A):
authentication information. If set to 1, this packet contains authentication information.
Sequence : For a multi-packet response, this field contains the Sequence:
sequence number of this packet. Packets in a multi-packet response For a multi-packet response, this field contains the sequence
are numbered starting with 0. The More Bit is set to 1 for all number of this packet. Packets in a multi-packet response are
packets but the last. numbered starting with 0. The More Bit is set to 1 for all
packets but the last.
Implementation : The version number of the implementation that Implementation:
defined the request code used in this message. An implementation The version number of the implementation that defined the request
number of 0 is used for a Request Code supported by all versions of code used in this message. An implementation number of 0 is used
the NTP daemon. The value 255 is reserved for future extensions. for a request code supported by all versions of the NTP daemon.
The value 255 is reserved for future extensions.
Request Code (Req Code) : An implementation-specific code which Request Code (Req Code):
specifies the operation being requested. A Request Code definition An implementation-specific code that specifies the operation being
includes the format and semantics of the data included in the packet. requested. A request code definition includes the format and
semantics of the data included in the packet.
Error (Err) : Set to 0 for a request. For a response, this field Error (Err):
contains an error code relating to the request. If the Error is non- Set to 0 for a request. For a response, this field contains an
zero, the operation requested wasn't performed. error code relating to the request. If the Error is nonzero, the
operation requested wasn't performed.
0 - no error 0: no error
1 - incompatible implementation number 1: incompatible implementation number
2 - unimplemented request code 2: unimplemented request code
3 - format error 3: format error
4 - no data available 4: no data available
7 - authentication failure 7: authentication failure
Count : The number of data items in the packet. Range is 0 to 500. Count:
The number of data items in the packet. Range is 0 to 500.
Must Be Zero (MBZ) : A reserved field set to 0 in requests and Must Be Zero (MBZ):
responses. A reserved field set to 0 in requests and responses.
Size : The size of each data item in the packet. Range is 0 to 500. Size:
The size of each data item in the packet. Range is 0 to 500.
Data : A variable-sized field containing request/response data. For Data:
requests and responses, the size in octets must be greater than or A variable-sized field containing request/response data. For
equal to the product of the number of data items (Count) and the size requests and responses, the size in octets must be greater than or
of a data item (Size). For requests, the data area is exactly 40 equal to the product of the number of data items (Count) and the
octets in length. For responses, the data area will range from 0 to size of a data item (Size). For requests, the data area is
500 octets, inclusive. exactly 40 octets in length. For responses, the data area will
range from 0 to 500 octets, inclusive.
Encryption KeyID : A 32-bit unsigned integer used to designate the Encryption KeyID:
key used for the Message Authentication Code. This field is included A 32-bit unsigned integer used to designate the key used for the
only when the A bit is set to 1. Message Authentication Code. This field is included only when the
A bit is set to 1.
Message Authentication Code : An optional Message Authentication Code Message Authentication Code:
defined by the version of the NTP daemon indicated in the An optional Message Authentication Code defined by the version of
Implementation field. This field is included only when the A bit is the NTP daemon indicated in the Implementation field. This field
set to 1. is included only when the A bit is set to 1.
Acknowledgements
Tim Plunkett created the original version of this document. Aanchal
Malhotra provided the initial version of the Security Considerations
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.
Miroshav Lichvar, Ulrich Windl, Dieter Sibold, J Ignacio Alvarez-
Hamelin, and Alex Campbell provided valuable comments on various
draft versions of this document.
Contributors
Dr. David Mills specified the vast majority of the mode 6 commands
during the development of [RFC1305] and deserves the credit for their
existence and use.
Author's Address Author's Address
Brian Haberman (editor) Brian Haberman (editor)
JHU JHU
Email: brian@innovationslab.net Email: brian@innovationslab.net
 End of changes. 128 change blocks. 
574 lines changed or deleted 750 lines changed or added

This html diff was produced by rfcdiff 1.48.