< draft-ietf-ntp-mode-6-cmds-08.txt   draft-ietf-ntp-mode-6-cmds-09.txt >
Network Working Group B. Haberman, Ed. Network Working Group B. Haberman, Ed.
Internet-Draft JHU Internet-Draft JHU
Intended status: Historic June 1, 2020 Intended status: Informational June 22, 2020
Expires: December 3, 2020 Expires: December 24, 2020
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-08 draft-ietf-ntp-mode-6-cmds-09
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 before the
advent of more modern control and management approaches. These 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 Network
Time Protocol application running on any IP network attached Time Protocol application running on any IP network attached
computer. The information in this document was originally described computer. The information in this document was originally described
in Appendix B of RFC 1305. The goal of this document is to provide a in Appendix B of RFC 1305. The goal of this document is to provide a
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 December 3, 2020. This Internet-Draft will expire on December 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Control Message Overview . . . . . . . . . . . . . . . . 3 1.1. Control Message Overview . . . . . . . . . . . . . . . . 3
1.2. Remote Facility Message Overview . . . . . . . . . . . . 4 1.2. Remote Facility Message Overview . . . . . . . . . . . . 5
2. NTP Control Message Format . . . . . . . . . . . . . . . . . 5 2. NTP Control Message Format . . . . . . . . . . . . . . . . . 5
3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Status Words . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. System Status Word . . . . . . . . . . . . . . . . . . . 8 3.1. System Status Word . . . . . . . . . . . . . . . . . . . 8
3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 10 3.2. Peer Status Word . . . . . . . . . . . . . . . . . . . . 10
3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 12 3.3. Clock Status Word . . . . . . . . . . . . . . . . . . . . 12
3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 12 3.4. Error Status Word . . . . . . . . . . . . . . . . . . . . 12
4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. NTP Remote Facility Message Format . . . . . . . . . 20 Appendix A. NTP Remote Facility Message Format . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
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 3, line 25 skipping to change at page 3, line 25
[RFC5905]. The control messages are described here as a historical [RFC5905]. The control messages are described here as a historical
record given their use within NTPv4. record given their use within NTPv4.
The publication of this document is not meant to encourage the The publication of this document is not meant to encourage the
developement and deployment of these control messages. This document developement 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. 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.,
SNMP) is not available. These control messages provide rudimentary
control and monitoring functions to manage a running instance of an
NTP server. These commands are not designed to be used for
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
skipping to change at page 15, line 20 skipping to change at page 15, line 20
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 Configure (8): The command data is parsed and applied as if supplied
in the daemon configuration file. The reference implementation in the daemon configuration file.
daemon requires authentication for this command.
Save Configuration (9): Write a snapshot of the current configuration Save Configuration (9): Write a snapshot of the current configuration
to the file name supplied as the command data. The reference to the file name supplied as the command data. Further, the command
implementation daemon requires authentication for this command. is refused unless a directory in which to store the resulting files
Further, the command is refused unless a directory in which to store has been explicitly configured by the operator.
the resulting files has been explicitly configured by the operator.
Read MRU (10): Retrieves records of recently seen remote addresses Read MRU (10): Retrieves records of recently seen remote addresses
and associated statistics. Command data consists of name=value pairs and associated statistics. Command data consists of name=value pairs
controlling the selection of records, as well as a requestor-specific controlling the selection of records, as well as a requestor-specific
nonce previously retrieved using this command or opcode 12, Request nonce previously retrieved using this command or opcode 12, Request
Nonce. The response consists of name=value pairs where some names Nonce. The response consists of name=value pairs where some names
can appear multiple times using a dot followed by a zero-based index can appear multiple times using a dot followed by a zero-based index
to distinguish them, and to associate elements of the same record to distinguish them, and to associate elements of the same record
with the same index. A new nonce is provided with each successful with the same index. A new nonce is provided with each successful
response. response.
skipping to change at page 16, line 10 skipping to change at page 16, line 6
Similar to Read MRU, response information uses zero-based indexes as Similar to Read MRU, response information uses zero-based indexes as
part of the variable name preceding the equals sign and value, where part of the variable name preceding the equals sign and value, where
each index relates information for a single address or network. This each index relates information for a single address or network. This
opcode requires authentication. opcode requires authentication.
Request Nonce (12): Retrieves a 96-bit nonce specific to the Request Nonce (12): Retrieves a 96-bit nonce specific to the
requesting remote address, which is valid for a limited period. requesting remote address, which is valid for a limited period.
Command data is not used in the request. The nonce consists of a 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, 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 the remote address, and salt known only to the server which varies
between daemon runs. The reference implementation honors nonces between daemon runs. Inclusion of the nonce by a managment agent
which were issued less than 16 seconds prior. Inclusion of the nonce demonstrates to the server that the agent can receive datagrams sent
by a managment agent demonstrates to the server that the agent can to the source address of the request, making source address
receive datagrams sent to the source address of the request, making "spoofing" more difficult in a similar way as TCP's three-way
source address "spoofing" more difficult in a similar way as TCP's handshake.
three-way handshake.
Unset Trap (31): Removes the requesting remote address and port from Unset Trap (31): Removes the requesting remote address and port from
the list of trap receivers. Command data is not used in the request. 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 If the address and port are not in the list of trap receivers, the
error code is 4, bad association. 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.
 End of changes. 9 change blocks. 
19 lines changed or deleted 23 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/