Network Time Protocol Version 4 (NTPv4) Extension Fields
RFC 7822

Document Type RFC - Proposed Standard (March 2016; No errata)
Updates RFC 5905
Last updated 2016-03-30
Stream IETF
Formats plain text pdf html bibtex
Stream WG state Submitted to IESG for Publication Apr 2016
Document shepherd Karen O'Donoghue
Shepherd write-up Show (last changed 2015-08-13)
IESG IESG state RFC 7822 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Brian Haberman
Send notices to (None)
IANA IANA review state Version Changed - Review Needed
IANA action state No IC
Internet Engineering Task Force (IETF)                        T. Mizrahi
Request for Comments: 7822                                       Marvell
Updates: 5905                                                   D. Mayer
Category: Standards Track                        Network Time Foundation
ISSN: 2070-1721                                               March 2016

        Network Time Protocol Version 4 (NTPv4) Extension Fields

Abstract

   The Network Time Protocol version 4 (NTPv4) defines the optional
   usage of extension fields.  An extension field, as defined in RFC
   5905, is an optional field that resides at the end of the NTP header
   and that can be used to add optional capabilities or additional
   information that is not conveyed in the standard NTP header.  This
   document updates RFC 5905 by clarifying some points regarding NTP
   extension fields and their usage with Message Authentication Codes
   (MACs).

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7822.

Copyright Notice

   Copyright (c) 2016 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
   (http://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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Mizrahi & Mayer              Standards Track                    [Page 1]
RFC 7822                  NTP Extension Fields                March 2016

Table of Contents

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................3
      2.1. Terminology ................................................3
      2.2. Terms and Abbreviations ....................................3
   3. NTP Extension Fields - RFC 5905 Update ..........................3
   4. Security Considerations .........................................6
   5. References ......................................................7
      5.1. Normative References .......................................7
      5.2. Informative References .....................................7
   Acknowledgments ....................................................8
   Authors' Addresses .................................................8

1.  Introduction

   The NTP header format consists of a set of fixed fields that may be
   followed by some optional fields.  Two types of optional fields are
   defined: Message Authentication Codes (MACs), and extension fields as
   defined in Section 7.5 of [NTPv4].

   If a MAC is used, it resides at the end of the packet.  This field
   can be either 24 octets long, 20 octets long, or a 4-octet
   crypto-NAK.

   NTP extension fields were defined in [NTPv4] as a generic mechanism
   that allows the addition of future extensions and features without
   modifying the NTP header format (Section 16 of [NTPv4]).

   The only currently defined extension fields are those fields used by
   the Autokey protocol [Autokey] and the Checksum Complement [RFC7821].
   The Autokey extension field is always followed by a MAC, and
   Section 10 of [Autokey] specifies the parsing rules that allow a host
   to distinguish between an extension field and a MAC.  However, a MAC
   is not mandatory after an extension field; an NTPv4 packet can
   include one or more extension fields without including a MAC.  This
   behavior is specified in Section 7.5 of [NTPv4] and in [Err3627], and
   is further clarified in this document.

   This document updates [NTPv4] (RFC 5905) by clarifying some points
   regarding the usage of extension fields.  These updates include
   changes to address errors found after the publication of [NTPv4] with
   respect to extension fields.  Specifically, this document updates
   Section 7.5 of [NTPv4], clarifying the relationship between extension
   fields and MACs, and defining the behavior of a host that receives an
Show full document text