idnits 2.17.1 draft-stenn-ntp-extended-information-00.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 (October 24, 2016) is 2740 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 October 24, 2016 5 Expires: April 27, 2017 7 Network Time Protocol Extended Information Extension Field 8 draft-stenn-ntp-extended-information-00 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 additinal 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 http://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 April 27, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 (http://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, MAC required), 0x2009 (Extended-Information, MAC 96 OPTIONAL), 0x0109 (Extended-Information Version 1, MAC required), 97 0x2109 (Extended-Information Version 1, MAC OPTIONAL) 99 Field Length: as needed 101 Payload: For Version 1, a two octet Content Descriptor field and a 102 two octet Content Data field, as described below. 104 Version 1 Content fields. 106 Content Descriptor 1 Content Data 1 107 0x0001 TAI offset in the low-order 8 bits, 24-31 108 0x0002 Interleave Mode indicator in Bit 23 109 0xFFFD Reserved (Zeroes) 111 Interleave Mode: 1 if the sender is in interleave mode, 0 otherwise 113 NTP Extension Field: Extended Information Version 1 Content Fields 115 Example: A system that wants to convey an offset to TAI of 36 116 seconds, and show it is in interleave mode. 118 0 1 2 3 119 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 120 +---------------+---------------+-------------------------------+ 121 | Field Type (0x2109) | Field Length (0x0008) | 122 +-------------------------------+-------------------------------+ 123 | 0x0003 | 0x0124 | 124 +-------------------------------+-------------------------------+ 126 NTP Extension Field: Extended Information V1, Example 128 3. Acknowledgements 130 The author wishes to acknowledge the contributions of Martin 131 Burnicki. 133 4. IANA Considerations 135 This memo requests IANA to allocate NTP Extension Field Types 137 0x0009 (Extended-Information, MAC Required) 139 0x2009 (Extended-Information, MAC OPTIONAL) 141 0x0109 (Extended-Information Version 1, MAC Required) 143 0x2109 (Extended-Information Version 1, MAC OPTIONAL) 145 for this proposal. 147 5. Security Considerations 149 Additional information TBD 151 6. Normative References 153 [RFC0958] Mills, D., "Network Time Protocol (NTP)", RFC 958, 154 DOI 10.17487/RFC0958, September 1985, 155 . 157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 158 Requirement Levels", BCP 14, RFC 2119, 159 DOI 10.17487/RFC2119, March 1997, 160 . 162 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 163 "Network Time Protocol Version 4: Protocol and Algorithms 164 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 165 . 167 Author's Address 169 Harlan Stenn 170 Network Time Foundation 171 P.O. Box 918 172 Talent, OR 97540 173 US 175 Email: stenn@nwtime.org