idnits 2.17.1 draft-ietf-dhc-dhcpv6-opt-sntp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 211. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 188. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 201. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 217), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 1) being 75 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2004) is 7105 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 3315 (ref. '1') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2030 (ref. '3') (Obsoleted by RFC 4330) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group V. Kalusivalingam 2 Internet-Draft Cisco Systems (India) Private Limited 3 Category: Standards Track October 2004 5 Simple Network Time Protocol Configuration Option for DHCPv6 6 draft-ietf-dhc-dhcpv6-opt-sntp-01 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document describes a new DHCPv6 option for passing a list of 42 Simple Network Time Protocol (SNTP) server addresses to a client. 44 1. Introduction 46 This document describes a new option called SNTP [3] servers Option 47 for passing information about SNTP servers in DHCPv6 [1]. 49 2. Requirements 51 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 52 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 53 document, are to be interpreted as described in RFC 2119 [2]. 55 3. Terminology 57 This document uses terminology specific to IPv6 and DHCPv6 as defined 58 in "Terminology" section of the DHCPv6 specification [1]. 60 4. Simple Network Time Protocol (SNTP) Servers option 62 The Simple Network Time Protocol Servers option provides a list of 63 one or more IPv6 addresses of SNTP [3] servers available to the 64 client for synchronization. The clients use these SNTP servers to 65 synchronize their system time to that of the standard time servers. 66 Clients MUST treat the list of SNTP servers as an ordered list. The 67 server MAY list the SNTP servers in the order of preference. 69 The option defined in this document can only be used to configure 70 information about SNTP servers that can be reached using IPv6. The 71 DHCP option to configure information about IPv4 SNTP servers can be 72 found in RFC 2132 [4]. Mechanisms for configuring IPv4/IPv6 dual- 73 stack applications are being considered, but are not specified in 74 this document. 76 The format of the Simple Network Time Protocol Servers option is as 77 shown below: 79 0 1 2 3 80 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 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 | OPTION_SNTP_SERVERS | option-len | 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 | | 85 | SNTP server (IPv6 address) | 86 | | 87 | | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | | 90 | SNTP server (IPv6 address) | 91 | | 92 | | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | ... | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 option-code: OPTION_SNTP_SERVERS (tbd) 99 option-len: Length of the 'SNTP server' fields in octets; It must be 100 a multiple of 16 102 SNTP server: IPv6 address of SNTP server 104 5. Appearance of this option 106 The SNTP servers option MUST NOT appear in other than the following 107 messages: Solicit, Advertise, Request, Renew, Rebind, 108 Information-Request and Reply. If this option appears in other than the 109 messages specified above, the receiver SHOULD ignore the option. 111 The option number for this option MAY appear in the Option Request 112 Option [1] in the following messages: Solicit, Request, Renew, 113 Rebind, Information-Request and Reconfigure. If this option number appear 114 in the Option Request Option in other than the messages specified above, 115 the receiver SHOULD ignore the option number. 117 6. Security Considerations 119 The SNTP servers option may be used by an intruder DHCPv6 server to 120 cause DHCPv6 clients to contact a rogue SNTP server, resulting in 121 invalid synchronization of time in client and finally leading to 122 time critical applications running inaccurately in client machine. 123 The time accuracy can be crucial to some security algorithms. For 124 example, it may cause expired certificates to gain a new life, making 125 the applications running on the client machine less secure. It can 126 even cause clients to set their time incorrectly, making them 127 vulnerable to replay attacks in protocols that use time stamps to 128 detect replays. 130 To avoid attacks through these options, the DHCPv6 client SHOULD use 131 authenticated DHCPv6 (see "Authentication of DHCP messages" section 132 in the DHCPv6 specification [1]). 134 7. IANA Considerations 136 IANA is requested to assign an option code to the following options 137 from the option-code space defined in "DHCPv6 Options" section of the 138 DHCPv6 specification [1]. 140 Option Name Value Described in 141 OPTION_SNTP_SERVERS tbd Section 4. 143 8. Normative References 145 [1] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. 146 Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 147 (DHCPv6)", RFC 3315, July 2003. 149 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 150 Levels", BCP 14, RFC 2119, March 1997. 152 9. Informative References 154 [3] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for 155 IPv4, IPv6 and OSI. Request for Comments (Informational) 2030, 156 Internet Engineering Task Force, October 1996. 158 [4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 159 Extensions", RFC 2132, March 1997. 161 Acknowledgements 163 Thanks to the DHC Working Group for their time and input into the 164 specification. In particular, thanks to (in alphabetical order) Bernie 165 Volz, Jim Bound, Margaret Wasserman, Pekka Savola, Ralph Droms, Robert 166 Elz and Thomas Narten for their thorough review. 168 Author's Address 170 Vijayabhaskar A Kalusivalingam 171 Cisco Systems (India) Private Limited, 172 No: 9, Brunton Road, 173 Bangalore - 560025 174 India 176 Phone: +91-80-51036615 177 EMail: vibhaska@cisco.com 179 Intellectual Property Statement 181 The IETF takes no position regarding the validity or scope of any 182 Intellectual Property Rights or other rights that might be claimed to 183 pertain to the implementation or use of the technology described in 184 this document or the extent to which any license under such rights 185 might or might not be available; nor does it represent that it has 186 made any independent effort to identify any such rights. Information 187 on the procedures with respect to rights in RFC documents can be 188 found in BCP 78 and BCP 79. 190 Copies of IPR disclosures made to the IETF Secretariat and any 191 assurances of licenses to be made available, or the result of an 192 attempt made to obtain a general license or permission for the use of 193 such proprietary rights by implementers or users of this 194 specification can be obtained from the IETF on-line IPR repository at 195 http://www.ietf.org/ipr. 197 The IETF invites any interested party to bring to its attention any 198 copyrights, patents or patent applications, or other proprietary 199 rights that may cover technology that may be required to implement 200 this standard. Please address the information to the IETF at 201 ietf-ipr@ietf.org. 203 Disclaimer of Validity 205 This document and the information contained herein are provided on an 206 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 207 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 208 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 209 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 210 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 211 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 213 Copyright Statement 215 Copyright (C) The Internet Society (2004). This document is subject 216 to the rights, licenses and restrictions contained in BCP 78, and 217 except as set forth therein, the authors retain all their rights. 219 Acknowledgment 221 Funding for the RFC Editor function is currently provided by the