idnits 2.17.1 draft-droms-dhc-dhcpv6-rfc868-servers-02.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 233. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (September 2005) is 6798 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. '2') (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Group R. Droms 3 Internet-Draft Cisco Systems, Inc. 4 Expires: March 5, 2006 D. Evans 5 ARRIS International, Inc. 6 September 2005 8 Time Protocol Servers and Time Offset Options for IPv6 DHCP 9 draft-droms-dhc-dhcpv6-rfc868-servers-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 5, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The Time Protocol Servers option for IPv6 DHCP (RFC 3315) carries the 43 IPv6 addresses of servers that a host should use for the Time 44 Protocol (RFC 868). The Time Offset option carries the offset in 45 seconds from Coordinated Universal Time (UTC) that a client may use 46 to determine its local time. 48 1. Introduction 50 The Time Protocol [1] can be used to obtain the current time from a 51 server. The Time Protocol Servers option defined in this document 52 provides an option to provide the IPv6 addresses of Time Protocol 53 servers to a host through DHCP [2]. 55 The Time Offset option defined in this document provides an option to 56 provide an offset in seconds from UTC that a client can use to 57 determine its local time. This option is only meaningful if the 58 server has knowledge of the physical location of the client. 60 The options defined in this document are based on the IPv4 DHCP [3] 61 Time Server and Time Offset options [4]. This document has no effect 62 on IPv4 DHCP, which will continue to use the Time Server option to 63 provide the IPv4 addresses of RFC 868 Time Protocol servers and the 64 Time Offset option to provide the offset between UTC and local time 65 to clients. 67 2. Terminology 69 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 70 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 71 interpreted as described in RFC2119 [5]. 73 Throughout this document, unless indicated otherwise for clarity, the 74 acronym "DHCP" refers to "Dynamic Host Configuration Protocol for 75 IPv6" [2]. 77 3. Format of the Time Protocol Servers option 79 The Time Protocol Servers option defines a list of Time Protocol 80 servers available to the DHCP client. The IPv6 address of each 81 server is included in the option. The addresses SHOULD be listed in 82 order of preference. The addresses MUST be unicast or anycast 83 addresses. 85 The Time Protocol Servers option has the following format: 87 0 1 2 3 88 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 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | OPTION_RFC868_SERVER | option-len | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | | 93 | server-address1 | 94 | | 95 | | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | | 98 | server-address2 | 99 | | 100 | | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 . . 103 . . 104 . . 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | | 107 | server-addressN | 108 | | 109 | | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 option-code OPTION_RFC868_SERVERS (TBD). 113 option-len 16 * N. 114 server-address1-N The IPv6 addresses of the Time Protocol servers. 116 4. Time Offset option 118 The Time Offset option specifies the offset in seconds from 119 Coordinated Universal Time (UTC) that the client should use to 120 determine its local time. The offset is expressed as a two's 121 complement 32-bit integer. A positive offset indicates a location 122 east of the zero meridian and a negative offset indicates a location 123 west of the zero meridian. It is recommended that this option be 124 used only when the concept of local time based on a 24-hour day is 125 known to be meaningful. 127 The Time Offset option has the following format: 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | OPTION_TIME_OFFSET | option-len | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | time_offset | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 option-code OPTION_TIME_OFFSET (TBD). 138 option-len 4. 139 server-address1-N Offset in seconds from UTC. 141 5. Security Considerations 143 A server could use this option to return invalid or incorrect 144 addresses or valid addresses of malicious Time Protocol servers to 145 the client. A server could use this option to return incorrect or 146 inappropriate time offset values to the client. 148 Authentication of DHCP messages [2] can be used to ensure that the 149 contents of this option are not altered in transit between the DHCP 150 server and client. 152 6. IANA Considerations 154 IANA is requested to assign an option code from the IPv6 DHCP options 155 registry to OPTION_RFC868_SERVER and OPTION_TIME_OFFSET. 157 7. Normative References 159 [1] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, 160 May 1983. 162 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 163 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 164 RFC 3315, July 2003. 166 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 167 March 1997. 169 [4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 170 Extensions", RFC 2132, March 1997. 172 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 173 Levels", BCP 14, RFC 2119, March 1997. 175 Authors' Addresses 177 Ralph Droms 178 Cisco Systems, Inc. 179 1414 Massachusetts Avenue 180 Boxborough, MA 01719 181 USA 183 Phone: +1 978.936.1674 184 Email: rdroms@cisco.com 186 D. R. Evans 187 ARRIS International, Inc. 188 7912 Fairview Road 189 Boulder, CO 80303 190 USA 192 Phone: +1 303.494.0394 193 Email: N7DR@arrisi.com 195 Full Copyright Statement 197 Copyright (C) The Internet Society (2005). 199 This document is subject to the rights, licenses and restrictions 200 contained in BCP 78, and except as set forth therein, the authors 201 retain all their rights. 203 This document and the information contained herein are provided on an 204 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 205 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 206 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 207 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 208 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 209 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 211 Intellectual Property 213 The IETF takes no position regarding the validity or scope of any 214 Intellectual Property Rights or other rights that might be claimed to 215 pertain to the implementation or use of the technology described in 216 this document or the extent to which any license under such rights 217 might or might not be available; nor does it represent that it has 218 made any independent effort to identify any such rights. Information 219 on the procedures with respect to rights in RFC documents can be 220 found in BCP 78 and BCP 79. 222 Copies of IPR disclosures made to the IETF Secretariat and any 223 assurances of licenses to be made available, or the result of an 224 attempt made to obtain a general license or permission for the use of 225 such proprietary rights by implementers or users of this 226 specification can be obtained from the IETF on-line IPR repository at 227 http://www.ietf.org/ipr. 229 The IETF invites any interested party to bring to its attention any 230 copyrights, patents or patent applications, or other proprietary 231 rights that may cover technology that may be required to implement 232 this standard. Please address the information to the IETF at 233 ietf-ipr@ietf.org. 235 Acknowledgment 237 Funding for the RFC Editor function is currently provided by the 238 Internet Society.