idnits 2.17.1 draft-stenn-ntp-extended-information-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2019) is 1853 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) == Missing Reference: 'IBID' is mentioned on line 89, but not defined == Unused Reference: 'RFC5905' is defined on line 198, but no explicit reference was found in the text ** Obsolete normative reference: RFC 958 (Obsoleted by RFC 1059, RFC 1119, RFC 1305) Summary: 1 error (**), 0 flaws (~~), 3 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 March 25, 2019 5 Expires: September 26, 2019 7 Network Time Protocol Extended Information Extension Field 8 draft-stenn-ntp-extended-information-04 10 Abstract 12 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 14 The source code and issues list for this draft can be found in 15 https://github.com/hstenn/ietf-ntp-extended-information-ef 17 The core network packet used by NTP has no spare bits available for 18 reporting additional state information and no larger data areas 19 available for larger amounts of information. This proposal offers a 20 new extension field that would contain this additional information. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 26, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 58 2. The Extended Information Extension Field . . . . . . . . . . 2 59 2.1. Version 0 Content Descriptor and Content Data fields . . 3 60 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 The core NTP packet format has changed little since RFC 958 [RFC0958] 69 was published in 1985. Since then, there has been demonstrated need 70 to convey additional information about NTP's state in an NTP packet 71 but no backward-compatible way to usurp the few otherwise potentially 72 available bits has been found, and no larger data areas are available 73 in the core packet structure. This proposal offers a new extension 74 field that would contain this additional information. 76 1.1. Requirements Language 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 2. The Extended Information Extension Field 84 The Field Type of the Extended Information EF includes a version 85 number field in the low-order bits of the first octet, to make it 86 easier to evolve this specification. The initial specification for 87 this proposal uses Version 0, which equates to 0x0009 [ADJUST AS 88 NEEDED BASED ON IANA, IF AN IANA REGISTRY IS USED]. A future 89 revision for Version 1 would use 0x0109 [IBID]. 91 The payload for Version 0 is comprised of a two octet Content 92 Descriptor followed by a two octet Content Data field, as described 93 below. 95 0 1 2 3 96 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 97 +---------------+---------------+-------------------------------+ 98 | Field Type | Field Length | 99 +-------------------------------+-------------------------------+ 100 | Content Descriptor 1 | Content Data 1 | 101 +---------------------------------------------------------------+ 103 NTP Extension Field: Extended Information 105 Field Type: TBD (Recommendation for IANA: 0x0009 (Extended- 106 Information, Version 0)) 108 Field Length: as needed 110 2.1. Version 0 Content Descriptor and Content Data fields 112 There are 16 bits available for state information in the Version 0 113 Extended Information Content Descriptor. These bits are allocated as 114 follows: 116 0x0001: TAI Offset is stored in the low-order 8 bits (the second 117 octet) of the Content Data. 119 0x0002: Interleave Mode indicator in the low order bit of the first 120 octet of the Content Data. [NOTE: this may not be useful, and it 121 can be removed if desired. It can serve as a belt-and-suspenders 122 way to identify when a packet contains interleaved timestamps.] 124 0xFFFD: Reserved for future versions. SHOULD be zeroes for Version 125 0, and the meaning of any nonzero values is unspecified. 127 The Content Data field of the Version 0 Extended Information 128 extension field is comprised of two octets, with the contents 129 allocated as follows: 131 0xXXNN: The low-order 8 bits (NNNN) are the TAI Offset. Any data in 132 the high-order 8 bits (XXXX) are not part of the TAI Offset. 134 0xX0XX: A value of 0 in the low-order bit of the first octet 135 indicates that the timestamps in the base packet are not 136 interleave-mode timestamps. 138 0xX1XX: A value of 1 in the low-order bit of the first octet 139 indicates that the timestamps in the base packet are interleave- 140 mode timestamps. 142 0xN2XX: thru 143 0xNDXX: Any of the seven high-order bits in the first octet are 144 reserved for future versions and SHOULD be zero for Version 0. 145 The meaning of any nonzero values is unspecified. 147 Content Descriptor 1 Content Data 1 148 0x0001 TAI offset in the low-order 8 bits, 24-31 149 0x0002 Interleave Mode indicator in Bit 23 150 0xFFFD Reserved (Zeroes) 152 Interleave Mode: 1 if the sender is in interleave mode, 0 otherwise 154 NTP Extension Field: Extended Information, Version 0 Content Fields 156 Example: A system that wants to convey an offset to TAI of 36 157 seconds, and show it is in interleave mode. 159 0 1 2 3 160 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 161 +---------------+---------------+-------------------------------+ 162 | Field Type (0x0009) | Field Length (0x0008) | 163 +-------------------------------+-------------------------------+ 164 | 0x0003 | 0x0124 | 165 +-------------------------------+-------------------------------+ 167 NTP Extension Field: Extended Information V0, Example 169 3. Acknowledgements 171 The author wishes to acknowledge the contributions of Martin Burnicki 172 and Sam Weiler. 174 4. IANA Considerations 176 This memo requests IANA to allocate NTP Extension Field Type 178 0x0009 (Extended-Information, Version 0) 180 for this proposal. 182 5. Security Considerations 184 No unusual or special security considerations are known to be 185 associated with this proposal. 187 6. Normative References 189 [RFC0958] Mills, D., "Network Time Protocol (NTP)", RFC 958, 190 DOI 10.17487/RFC0958, September 1985, 191 . 193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, 195 DOI 10.17487/RFC2119, March 1997, 196 . 198 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 199 "Network Time Protocol Version 4: Protocol and Algorithms 200 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 201 . 203 Author's Address 205 Harlan Stenn 206 Network Time Foundation 207 P.O. Box 918 208 Talent, OR 97540 209 US 211 Email: stenn@nwtime.org