NTP Server Identifier Extension
draft-grant-ntp-server-identifier-extension-00

Network Time Protocols                                          S. Grant
Internet-Draft                                                          
Intended status: Informational                                D. Venhoek
Expires: 23 January 2027                                    22 July 2026

                    NTP Server Identifier Extension
             draft-grant-ntp-server-identifier-extension-00

Abstract

   This document defines an extension field that allows operators of NTP
   services the ability to provide additional information about their
   services to clients which request it.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-grant-ntp-server-identifier-
   extension/.

   Discussion of this document takes place on the Network Time Protocols
   Working Group mailing list (mailto:ntp@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/ntp/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/ntp/.

   Source for this draft and an issue tracker can be found at
   https://github.com/signalsforgranted/draft-grant-ntp-server-
   identifier-extension.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 23 January 2027.

Grant & Venhoek          Expires 23 January 2027                [Page 1]
Internet-Draft            NTP Server Identifier                July 2026

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   3.  Current Deployments . . . . . . . . . . . . . . . . . . . . .   3
   4.  The Server Identifier Extension Field . . . . . . . . . . . .   3
     4.1.  Use of the Server Identifier Extension Field  . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Operators of NTP services may choose to have system architectures
   which result in multiple servers responding for the same IP address.
   This is particularly notable in the case of deployments which use
   load balancing of UDP traffic, or the use of anycast IP addresses.
   In such situations, the server operator may want to provide an
   indication which actual server responded to a request.  This
   information can be useful in identifying infrastructure, providing
   ongoing monitoring and assist in triaging faults or issues with
   services.

2.  Conventions and Definitions

   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.

Grant & Venhoek          Expires 23 January 2027                [Page 2]
Internet-Draft            NTP Server Identifier                July 2026

3.  Current Deployments

   Many operators use various methods to include diagnostic information
   about the network segment, datacentre location, region, or other
   details pertaining to their infrastructure in NTP responses with the
   NTP reference identifier most commonly being used.

4.  The Server Identifier Extension Field

   The Server Identifier field contains the following structure, based
   on the general structure of an NTP extension field defined in
   [RFC5905]:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Type = TBD              |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                      Server Identifier                        .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: Extension Field Structure

   Field Type:  The type which identifies the Server Identifier
      extension field.  To be determined by IANA.  (Draft
      implementations: *0xf101*)

   Length:  Length of the Server Identifier field.  The length is in
      octets expressed as an unsigned 16-bit integer and it includes the
      header itself.  Implementations SHALL keep the length of this
      extension field at less than 256 bytes.

   Server Identifier:  A Unicode string containing information about the
      server.  In requests, this field shall be filled with zeroes.  The
      length of this field SHALL be chosen such that the length
      requirements on extension fields from the NTP version in use are
      satisfied.  If doing this requires padding of the string, the
      sender shall use zeroes to pad this field to the required length.

4.1.  Use of the Server Identifier Extension Field

   To request the server identifier of a server, a client includes in
   its request a Server Identifier Extension Field.  This extension
   field shall be sent with a zeroed out server-identifier field, of
   length sufficient that the client expects the servers identifier to
   fit within the length of the server identifier field in its request.

Grant & Venhoek          Expires 23 January 2027                [Page 3]
Internet-Draft            NTP Server Identifier                July 2026

   On receiving a Server Identifier Extension Field a server MAY choose
   to send its server identifier in the response.  If it chooses to do
   so, it shall include a Server Identifier Extension Field in the
   response.  The length of this Extension field SHALL be at most the
   length of the Server Identifier Extension Field in the request.  If
   the server's identifier doesn't fit within the length requested by
   the client, the server SHALL truncate the identifier, providing as
   many bytes of it as fit within the space chosen in the request.  If
   the identifier is shorter than the length of Server Identifier field
   in the Server Identifier Extension Field, the server MAY choose to
   pad the identifier with zeroes to make the length of the request and
   response identical.

5.  Security Considerations

   Operators should note that NTP packets are not confidential and that
   revealing this information to clients may expose sensitive details
   about their network, services, or their configuration.  Deployments
   not wishing to expose this data to clients should be configured to
   filter or ignore this extension on non-monitoring interfaces.

   There is a risk of amplification with this extension field if servers
   blindly respond with the full server identifier on any request.  To
   avoid this risk, it is important servers stick closely to the
   guidance provided in section Section 4.1.

6.  IANA Considerations

   IANA is requested to allocate the following entries in the NTP
   Extension Field Types registry [RFC5905]:

              +============+===================+===========+
              | Field Type | Meaning           | Reference |
              +============+===================+===========+
              | TBD        | Server Identifier | this memo |
              +------------+-------------------+-----------+

                                 Table 1

7.  Normative References

   [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/rfc/rfc2119>.

Grant & Venhoek          Expires 23 January 2027                [Page 4]
Internet-Draft            NTP Server Identifier                July 2026

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5905>.

   [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/rfc/rfc8174>.

Acknowledgments

   The authors would like to acknowledge Marco Davids, Miroslav Lichvar,
   Giovane Moura, and Ruben Nijveld for providing thoughtful discussion
   and inspiration for this document.

Authors' Addresses

   Sarah Grant
   Email: sarah.grant.ietf@gmail.com

   David Venhoek
   Email: david@venhoek.nl

Grant & Venhoek          Expires 23 January 2027                [Page 5]