idnits 2.17.1 draft-stenn-ntp-extended-information-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5905], [RFC0958]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 21, 2018) is 2250 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 958 (Obsoleted by RFC 1059, RFC 1119, RFC 1305) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Stenn 3 Internet-Draft Network Time Foundation 4 Intended status: Standards Track February 21, 2018 5 Expires: August 25, 2018 7 Network Time Protocol Extended Information Extension Field 8 draft-stenn-ntp-extended-information-02 10 Abstract 12 The network packet format used by NTP has changed very little between 13 NTPv1, defined by RFC 958 [RFC0958] in 1985, and NTPv4, defined by 14 RFC 5905 [RFC5905]. The core network packet used by NTP has no spare 15 bits available for reporting additional state information and no 16 larger data areas available for larger amounts of information. This 17 proposal offers a new extension field that would contains this 18 additional information. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 25, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 2. The Extended Information Extension Field . . . . . . . . . . 2 57 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Introduction 65 The core NTP packet format has changed little since RFC 958 [RFC0958] 66 was published in 1985. Since then, there has been demonstrated need 67 to convey additional information about NTP's state in an NTP packet, 68 but no backward-compatible way to usurp the few otherwise potentially 69 available bits has been found, and no larger data areas are available 70 in the core packet structure. This proposal offers a new extension 71 field that would contain this additional information. 73 1.1. Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 2. The Extended Information Extension Field 81 The Field Type of the Extended Information EF includes a version 82 specification, to make it easier to evolve this specification. 84 0 1 2 3 85 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 86 +---------------+---------------+-------------------------------+ 87 | Field Type | Field Length | 88 +-------------------------------+-------------------------------+ 89 | Content Descriptor 1 | Content Data 1 | 90 +---------------------------------------------------------------+ 92 NTP Extension Field: Extended Information 94 Field Type: TBD (Recommendation for IANA: 0x0009 (Extended- 95 Information), 0x0109 (Extended-Information Version 1) 96 Field Length: as needed 98 Payload: For Version 1, a two octet Content Descriptor field and a 99 two octet Content Data field, as described below. 101 Version 1 Content fields. 103 Content Descriptor 1 Content Data 1 104 0x0001 TAI offset in the low-order 8 bits, 24-31 105 0x0002 Interleave Mode indicator in Bit 23 106 0xFFFD Reserved (Zeroes) 108 Interleave Mode: 1 if the sender is in interleave mode, 0 otherwise 110 NTP Extension Field: Extended Information Version 1 Content Fields 112 Example: A system that wants to convey an offset to TAI of 36 113 seconds, and show it is in interleave mode. 115 0 1 2 3 116 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 117 +---------------+---------------+-------------------------------+ 118 | Field Type (0x0109) | Field Length (0x0008) | 119 +-------------------------------+-------------------------------+ 120 | 0x0003 | 0x0124 | 121 +-------------------------------+-------------------------------+ 123 NTP Extension Field: Extended Information V1, Example 125 3. Acknowledgements 127 The author wishes to acknowledge the contributions of Martin 128 Burnicki. 130 4. IANA Considerations 132 This memo requests IANA to allocate NTP Extension Field Types 134 0x0009 (Extended-Information) 136 0x0109 (Extended-Information Version 1) 138 for this proposal. 140 5. Security Considerations 142 Additional information TBD 144 6. Normative References 146 [RFC0958] Mills, D., "Network Time Protocol (NTP)", RFC 958, 147 DOI 10.17487/RFC0958, September 1985, 148 . 150 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 151 Requirement Levels", BCP 14, RFC 2119, 152 DOI 10.17487/RFC2119, March 1997, 153 . 155 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 156 "Network Time Protocol Version 4: Protocol and Algorithms 157 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 158 . 160 Author's Address 162 Harlan Stenn 163 Network Time Foundation 164 P.O. Box 918 165 Talent, OR 97540 166 US 168 Email: stenn@nwtime.org