idnits 2.17.1 draft-ietf-dhc-timezone-option-05.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 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 423. ** 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2132, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2132, updated by this document, for RFC5378 checks: 1995-06-01) -- 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 (November 29, 2006) is 6352 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 3315 (ref. '5') (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Obsolete informational reference (is this intentional?): RFC 2445 (ref. '9') (Obsoleted by RFC 5545) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Updates: 2132 (if approved) P. Eggert 5 Expires: June 2, 2007 UCLA 6 November 29, 2006 8 A Timezone Option for DHCP 9 draft-ietf-dhc-timezone-option-05.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 June 2, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Two common ways to communicate timezone information are POSIX 1003.1 43 timezone strings and timezone database names. This memo specifies 44 DHCP options each of those methods. The DHCP v4 time offset option 45 is deprecated. 47 1. Introduction 49 This memo specifies a means to provide hosts with more accurate 50 timezone information than was previously available. To do this we 51 make use of two commonly used methods to configure timezones: 52 o POSIX TZ strings 53 o Reference to the TZ Database 55 POSIX [1] provides a standard for how to express timezone information 56 in a character string. Use of such a string can provide accuracy for 57 at least one transition into and out of daylight saving time, and 58 possibly for more transitions if the transitions are regular enough 59 (e.g., "second Sunday in March at 02:00 local time"). However, for 60 accuracy over longer periods, that involve daylight-saving rule 61 changes or other irregular changes, a more detailed mechanism is 62 necessary. 64 The TZ Database [7] that is used in many operating systems provides 65 backwards consistency and accuracy for almost all real-world 66 locations since 1970. The TZ database also attempts to provide a 67 stable set of human readable timezone identifiers. In addition, many 68 systems already make use of the TZ database, and so the names used 69 are a defacto standard. Because the TZ database contains more 70 information, one can heuristically derive the POSIX information from 71 a TZ identifier (see [10] for an example), but the converse is not 72 true. 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [2]. 78 1.1. Related Work 80 Dynamic Host Configuration Protocol (DHCP) [3] provides a means for 81 hosts to receive configuration information relating to their current 82 location within an IP version 4 network. [5] similarly does so for IP 83 version 6 networks. RFC2132 [4] specifies an option to provide a 84 client timezone information in the form of an offset in seconds from 85 UTC. The information provided in that option is insufficient for the 86 client to determine whether it is in daylight saving time and when to 87 change into and out of daylight saving time (DST). In order for the 88 client to properly represent local wall clock time in a consistent 89 and accurate fashion the DHCP server would have to time lease 90 expirations of affected clients to the beginning or end of DST, thus 91 effecting a self stress test (to say the least) at the appointed 92 hour. 94 In addition, an offset is not sufficient to determine the actual 95 timezone in which a client resides, and thus there is no means to 96 derive a human readable abbreviation such as "EST" or "EDT". 98 VTIMEZONE elements are defined in the iCalendar specification.[9] 99 Fully specified they provide a level of accuracy similar to the TZ 100 database. However, because there is currently no global registry of 101 VTIMEZONE TZIDs (although one has been proposed; see [8]), complete 102 accuracy requires that a full entry must be specified. To achieve 103 the same information would range from 300 octets upwards with no 104 particular bound. Furthermore, at the time of this writing the 105 authors are aware of no operating system that natively takes 106 advantage of VTIMEZONE entries. It might be possible to include an 107 option for a TZURL. However, in a cold start environment, it will be 108 bad enough that devices are stressing the DHCP server, and perhaps 109 unwise to similarly afflict other components. 111 2. New Timezone Options for DHCPv4 113 The following two options are defined for DHCPv4: 115 PCode Len TZ-POSIX String 116 +-----+-----+------------------------------+ 117 | TBD | N | IEEE 1003.1 String | 118 +-----+-----+------------------------------+ 120 TCode Len TZ-Database String 121 +-----+-----+------------------------------+ 122 | TBD | N | Reference to the TZ Database | 123 +-----+-----+------------------------------+ 125 PCode and TCode are TBD and will be allocated by IANA according to 126 RFC-2939 [6]. 128 Len is the one-octet value of the length of the succeeding string for 129 each option. 131 The string values that follow Len are described below. Note that 132 they are NOT terminated by an ASCII NULL. 134 3. New Timezone Options for DHCPv6 136 The semantics and content of the DHCPv6 encoding of these options are 137 exactly the same as the encoding described for DHCPv4, other than 138 necessary differences between the way options are encoded in DHCPv4 139 and DHCPv6. 141 Specifically, the DHCPv6 new timezone options are described below: 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | OPTION_NEW_POSIX_TIMEZONE | option-length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | TZ POSIX String | 149 | ... | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 option-code: OPTION_NEW_POSIX_TIMEZONE(TBD) 154 option-length: the number of octets of the TZ POSIX String Index 155 described below. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | OPTION_NEW_TZDB_TIMEZONE | option-length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | TZ Name | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 option-code: OPTION_NEW_TZDB_TIMEZONE(TBD) 167 option-length: the number of octets of the TZ Database String Index 168 described below. 170 4. The TZ POSIX String 172 TZ POSIX string is a string suitable for the TZ variable as specified 173 by [1] in Section 8.3, with the exception that a string may not begin 174 with a colon (":"). This string is NOT terminated by an ASCII NULL. 175 Here is an example: 177 EST5EDT4,M3.2.0/02:00,M11.1.0/02:00 179 In this case, the string is interpreted as a timezone that is 180 normally five hours behind UTC, and four hours behind UTC during DST, 181 which runs from the second Sunday in March at 02:00 local time 182 through the first Sunday in November at 02:00 local time. Normally 183 the timezone is abbreviated "EST" but during DST it is abbreviated 184 "EDT". 186 Clients and servers implementing other timezone options MUST support 187 this option for basic compatibility. 189 5. The TZ Name 191 TZ Name is the name of a Zone entry in the database commonly referred 192 to as the TZ database. In order for this option to be useful, the 193 client must already have a copy of the database. This string is NOT 194 terminated with an ASCII NULL. 196 An example string is Europe/Zurich. 198 Clients must already have a copy of the TZ Database for this option 199 to be useful. Configuration of the database is beyond the scope of 200 this document. A client that supports this option SHOULD prefer this 201 option to POSIX string if it recognizes the TZ Name that was 202 returned. If it doesn't recognize the TZ Name the client MUST ignore 203 this option. 205 6. Use of the timezone string(s) returned from the server 207 This specification presumes the DHCP server has some means of 208 identifying which timezone the client is in. One obvious approach 209 would be to associate a subnet or group of subnets with a timezone, 210 and respond with this option accordingly. 212 When considering which option to implement on a client, one must 213 choose between the TZ Name, which should be easier for users to 214 configure and which provides accuracy over longer historical periods, 215 and the TZ POSIX string, which does not require regular updating of a 216 copy of the TZ Database. The TZ Name is better for most use, in 217 particular those cases where the timezone name might persist in a 218 database for long periods of time, but the TZ POSIX string may be 219 more suitable for small-footprint applications that are expertly 220 maintained. 222 So that clients need not request both options, servers who implement 223 either of timezone option SHOULD implement the other one as well. 224 This association can be established by the server's administrator. A 225 basic server can transmit option values to the client without parsing 226 or validating them. A more advanced server might have a copy of the 227 TZ database and validate TZ names against this copy, or derive TZ 228 POSIX strings heuristically from TZ names to simplify administration. 230 As a matter of practicality the client will use this information at 231 its discretion to configure the current timezone in which it resides. 233 It will periodically be necessary for a DHCP server to update the 234 timezone string, based on administrative changes made by local 235 jurisdictions (say, for instance, counties in Indiana). While the 236 authors do not expect this to be a lower bound on a lease time in the 237 vast majority of cases, there may be times when anticipation of a 238 change dictates prudence, as certain governments give little if any 239 notification. 241 The effect of a changed timezone on client applications is not 242 specified by this memo, but it may be helpful to note common problems 243 in this area. Often, client applications consult the timezone 244 setting only during process initialization, or inherit the setting 245 from a parent process, so existing processes on a client may ignore a 246 timezone change returned from the server. Sometimes it is normal and 247 expected for processes on the same client to have different timezone 248 settings (e.g., remote logins), and so client implementations should 249 consider these ramifications of changing timezone settings of 250 existing processes. 252 7. The New Timezone Option and Lease times 254 When a lease has expired and new information is not forthcoming, the 255 client MAY continue to use timezone information returned by the 256 server. This follows the principle of least astonishment. 258 8. Deprecation of Time Offset Option 260 Because this option provides a superset of functionality to the 261 previous IPv4 time offset option (tag 2), and in order to maintain 262 consistency between IPv4 and IPv6 implementation, the older option is 263 deprecated. Current implementations that support the time offset 264 IPv4 option SHOULD implement this option also. Other implementations 265 SHOULD implement this option, and SHOULD NOT implement the time 266 offset IPv4 option. As a matter of transition, clients that already 267 use the time offset option MAY request the time offset option and the 268 timezone option. 270 9. Security Considerations 272 An attacker could provide erroneous information to a client. It is 273 possible that someone might miss a meeting or otherwise show up 274 early, or that heavy machinery or other critical functions might act 275 at the wrong time or fail to act. If clients have job processing 276 tools such as cron that operate on wall clock time it is possible 277 that certain jobs could be triggered either earlier or later, or even 278 repeated or skipped entirely if scheduled during a DST transition. 279 In such cases, the client operating system might do well to confirm 280 timezone changes with a human. 282 Clients using the POSIX option should beware of any time zone setting 283 specifying unusual characters (e.g., control characters) in the 284 standard or daylight-saving abbreviations, as this might well trigger 285 security-relevant bugs in applications. 287 Clients using the POSIX option should also be suspicious of any 288 timezone setting whose UTC offset exceeds 25 hours (the POSIX limit, 289 if the default daylight-saving offset is used). As of this writing, 290 the maximum UTC offset is 14 hours in practice, but governments may 291 extend this somewhat in the future. 293 10. IANA Considerations 295 The IANA is requested to allocate DHCPv4 and DHCPv6 option codes for 296 this purpose and reference this document in those allocations for 297 both DHCPv4 and DHCPv6. 299 The IANA is requested to annotate the time offset IPv4 option (tag 2) 300 as deprecated, with a reference to this memo. 302 11. Acknowledgments 304 This document specifies a means to exchange timezone information. 305 The hard part is actually collecting changes to the various databases 306 from scattered sources around the world. The many volunteers on the 307 mailing list tz@elsie.nci.nih.gov have done this nearly thankless 308 task for many years. Thanks also go to Ralph Droms, Bernie Volz, Ted 309 Lemon, Lisa Dusseault, John Hawkinson, Stig Venaas, and Simon 310 Vaillancourt for their efforts to improve this work. 312 12. References 314 12.1. Normative References 316 [1] "Standard for Information Technology - Portable Operating System 317 Interface (POSIX) - Base Definitions", IEEE Std 1003.1-2004, 318 December 2004. 320 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 321 Levels", BCP 14, RFC 2119, March 1997. 323 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 324 March 1997. 326 [4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 327 Extensions", RFC 2132, March 1997. 329 [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 330 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 331 RFC 3315, July 2003. 333 [6] Droms, R., "Procedures and IANA Guidelines for Definition of New 334 DHCP Options and Message Types", BCP 43, RFC 2939, 335 September 2000. 337 [7] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight 338 Saving Time Data", . 340 12.2. Informational References 342 [8] Vaillancourt, S., "Calconnect.org TC Timezone Technical 343 Committee: Timezone Registry and Service Recommendations", 344 April 2006. 346 [9] Dawson, F. and Stenerson, D., "Internet Calendaring and 347 Scheduling Core Object Specification (iCalendar)", RFC 2445, 348 November 1998. 350 [10] Eggert, P. and E. Reingold, "cal-dst.el --- calendar functions 351 for daylight savings rules", . 354 Appendix A. Changes 356 [The RFC Editor is requested to remove this section at publication.] 357 o -04: correct missing RFC 2119 boilerplate. 358 o -03: post last call comments include changing option length, 359 fixing of quotes and typos, additional reference to cal-dst.el, 360 additional security considerations, cleanup of deprecation text. 361 Reorganized intro to include related work section. Added "SHOULD 362 implement both options". 364 o -02: remove Microsoft (no need for special case); modify reference 365 o -01: change from suboptions to options 366 o -00 (WG submission): add length field to Microsoft suboption, 367 clarifying text about when to prefer which suboption, indicate 368 that the POSIX string is NOT null terminated; add additional 369 justification; add deprecation text; remove extraneous text that 370 says that this document will not prescribe client behavior 371 regarding multiple options (we just did). 372 o -02: fix references to the TZ database; add additional security 373 considerations; clarify POSIX example; reference Doug Royer 374 registry draft; add Paul Eggert as co-author(who did all the 375 above) 376 o -01: clarify uses of each suboption; reset suboption sizes; add 377 explanation for not using VTIMEZONEs; add acknowlegments. 378 o initial revision 380 Authors' Addresses 382 Eliot Lear 383 Cisco Systems GmbH 384 Glatt-com 385 Glattzentrum, ZH CH-8301 386 Switzerland 388 Phone: +41 1 878 9200 389 Email: lear@cisco.com 391 Paul Eggert 392 UCLA 393 Computer Science Department 394 4532J Boelter Hall 395 Los Angeles, CA 90095 396 USA 398 Phone: +1 310 825 3886 399 Email: eggert@cs.ucla.edu 401 Intellectual Property Statement 403 The IETF takes no position regarding the validity or scope of any 404 Intellectual Property Rights or other rights that might be claimed to 405 pertain to the implementation or use of the technology described in 406 this document or the extent to which any license under such rights 407 might or might not be available; nor does it represent that it has 408 made any independent effort to identify any such rights. Information 409 on the procedures with respect to rights in RFC documents can be 410 found in BCP 78 and BCP 79. 412 Copies of IPR disclosures made to the IETF Secretariat and any 413 assurances of licenses to be made available, or the result of an 414 attempt made to obtain a general license or permission for the use of 415 such proprietary rights by implementers or users of this 416 specification can be obtained from the IETF on-line IPR repository at 417 http://www.ietf.org/ipr. 419 The IETF invites any interested party to bring to its attention any 420 copyrights, patents or patent applications, or other proprietary 421 rights that may cover technology that may be required to implement 422 this standard. Please address the information to the IETF at 423 ietf-ipr@ietf.org. 425 Disclaimer of Validity 427 This document and the information contained herein are provided on an 428 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 429 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 430 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 431 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 432 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 433 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 435 Copyright Statement 437 Copyright (C) The Internet Society (2006). This document is subject 438 to the rights, licenses and restrictions contained in BCP 78, and 439 except as set forth therein, the authors retain all their rights. 441 Acknowledgment 443 Funding for the RFC Editor function is currently provided by the 444 Internet Society.