RFC 4833

Timezone Options for DHCP

📅 published April 2007, from ietf

RFC 4833: Timezone Options for DHCP ✨

Okay bestie, let's get into it 🫶 This one is RFC 4833, and it's all about giving DHCP clients timezone info that's actually accurate. Here's the title block so you know who's behind it 💅

  • Network Working Group: the IETF working group this was produced under
  • Authors: E. Lear (Cisco Systems GmbH) and P. Eggert (UCLA)
  • Category: Standards Track
  • Date: April 2007
  • Updates: RFC 2132 🎀 (the title block doesn't list anything it obsoletes)

Status of This Memo 🧾

Okay, so this is the official paperwork part 📋 This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍 Distribution of this memo is unlimited 🌈

Copyright (C) The IETF Trust (2007). Legal stuff, but it's giving official ✨

Abstract 🦋

Okay so there are two common ways to share timezone info: POSIX 1003.1 timezone strings and timezone database names 💖 This memo defines DHCP options for each of those methods. Also, the DHCPv4 time offset option is now deprecated 🥀

1. Introduction 🌸

Okay so this memo is all about giving hosts timezone info that's more accurate than what they had before 🙌 It does that by using two methods people already use to set timezones:

  • POSIX TZ strings
  • Reference to the name of the time zone entry in the TZ Database

POSIX [1] gives us a standard way to write timezone info as a character string 🧚 A string like that can be accurate for at least one switch into and out of daylight saving time (DST), and maybe more switches if they follow a regular pattern (e.g., "second Sunday in March at 02:00 local time"). But for accuracy over longer stretches that include daylight-saving rule changes or other irregular changes, you need a more detailed mechanism 😭

The TZ Database [7] is used in tons of operating systems 💅 It's backwards consistent and accurate for almost every real-world location since 1970 ✨ It also tries to keep a stable set of human-readable timezone identifiers 🍓 Since lots of systems already use it, those names are basically a de facto standard, which is so iconic 👑 The TZ database holds more info than POSIX, so you can heuristically derive the POSIX info from a TZ identifier (see [10] for an example), but the reverse isn't true 🙈

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] 📖

Dynamic Host Configuration Protocol (DHCP) [3] gives hosts their configuration info for their current location within an IP version 4 network 🌐 [5] does the same thing for IP version 6 networks 💜 RFC 2132 [4] defines an option that gives client timezone info as an offset in seconds from UTC 🕰️ Lowkey, that's not enough, because the client can't tell whether it's in daylight saving time or when to switch in or out of it 😬 To show local wall clock time in a consistent and accurate way, the DHCP server would have to time lease expirations of affected clients to the start or end of DST, which would be a self stress test (to say the least) at that exact hour 💀

An offset also isn't enough to figure out the actual timezone a client is in, so there's no way to derive a human-readable abbreviation like "EST" or "EDT" 🫠

VTIMEZONE elements are defined in the iCalendar specification [9] 🗓️ When fully specified, they're about as accurate as the TZ database 🌟 But there's currently no global registry of VTIMEZONE TZIDs (although one has been proposed; see [8]), so getting complete accuracy means specifying a full entry 📜 That would take somewhere from 300 octets upwards, with no particular bound 😵 Also, at the time of writing, the authors weren't aware of any operating system that natively takes advantage of VTIMEZONE entries 🙃 Including an option for a TZURL might be possible 🔗 But in a cold start environment, devices are already stressing the DHCP server, so it might be unwise to stress other components too 🥺

2. New Timezone Options for DHCPv4 🎀

Two options are defined for DHCPv4 🫶

        PCode  Len   TZ-POSIX String
       +-----+-----+------------------------------+
       | 100 |  N  | IEEE 1003.1 String           |
       +-----+-----+------------------------------+

        TCode  Len   TZ-Database String
       +-----+-----+------------------------------+
       | 101 |  N  | Reference to the TZ Database |
       +-----+-----+------------------------------+

Per RFC 2939 [6], IANA allocated PCode (100) and TCode (101) 🧾

Len is a one-octet value holding the length of the string that comes after it, for each option ✨ The string values that follow Len are described below. Note that they are NOT terminated by an ASCII NULL 🙅‍♀️

3. New Timezone Options for DHCPv6 🦋

The DHCPv6 encoding of these options has exactly the same semantics and content as the DHCPv4 encoding, except for the necessary differences in how options get encoded in DHCPv4 versus DHCPv6 🔄 Here are the DHCPv6 new timezone options 👇

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  OPTION_NEW_POSIX_TIMEZONE    |         option-length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      TZ POSIX String                          |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code: OPTION_NEW_POSIX_TIMEZONE(41)

option-length: the number of octets of the TZ POSIX String Index described below 🔢

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  OPTION_NEW_TZDB_TIMEZONE    |          option-length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          TZ Name                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code: OPTION_NEW_TZDB_TIMEZONE(42)

option-length: the number of octets of the TZ Database String Index described below 🔢

4. The TZ POSIX String 🌙

A TZ POSIX string is a string you can use for the TZ variable, as specified by [1] in Section 8.3 💫 The one exception is that the string may not begin with a colon (":"). This string is NOT terminated by an ASCII NULL. Here's an example 👀

EST5EDT4,M3.2.0/02:00,M11.1.0/02:00

In this case, the string is read as a timezone that's normally five hours behind UTC, and four hours behind UTC during DST 🕐 DST runs from the second Sunday in March at 02:00 local time through the first Sunday in November at 02:00 local time 🌞 Normally the timezone is abbreviated "EST", but during DST it's abbreviated "EDT" 🍂

Clients and servers implementing other timezone options MUST support this option for basic compatibility 🫶

5. The TZ Name 🗺️

TZ Name is the name of a Zone entry in the database commonly called the TZ database 🌍 More specifically, in the database's textual form, the string refers to the name field of a zone line. For this option to be useful, the client must already have a copy of the database. This string is NOT terminated with an ASCII NULL 🙅‍♀️

An example string is Europe/Zurich 🇨🇭

Clients must already have a copy of the TZ Database for this option to be useful 📚 Configuring the database is beyond the scope of this document. A client that supports this option SHOULD prefer this option to the POSIX string if it recognizes the TZ Name that was returned 💖 If it doesn't recognize the TZ Name, the client MUST ignore this option 🙈

6. Use of the Timezone String(s) Returned from the Server 🖥️

This specification assumes the DHCP server has some way of working out which timezone the client is in 🧠 One obvious approach would be to link a subnet, or a group of subnets, to a timezone, and then respond with this option to match 🎯

When picking which option to implement on a client, you have to choose between the TZ Name and the TZ POSIX string 🤔 The TZ Name should be easier for users to configure, and it's accurate over longer historical periods ✨ The TZ POSIX string doesn't need a copy of the TZ Database to be regularly updated 🧹 The TZ Name is better for most uses, especially where a timezone name might stick around in a database for a long time 💅 The TZ POSIX string may be a better fit for small-footprint applications that are expertly maintained 🧚

So clients don't have to request both options, servers that implement either timezone option SHOULD implement the other one as well 🫶 The server's administrator can set up this association 🛠️ A basic server can pass option values to the client without parsing or validating them 📦 A more advanced server might keep a copy of the TZ database and validate TZ names against it, or derive TZ POSIX strings from TZ names heuristically to make administration easier 🌈

As a practical matter, the client uses this information at its own discretion to set the current timezone where it is 📍

A DHCP server will periodically need to update the timezone string, because local jurisdictions make administrative changes (say, counties in Indiana, for instance) 🏛️ The authors don't expect this to be a lower bound on a lease time in the vast majority of cases 🙌 But there may be times when anticipating a change is the prudent move, since certain governments give little if any notice 😬

The effect of a changed timezone on client applications isn't specified by this memo, but it's helpful to know the common problems in this area 🔍 Client applications often check the timezone setting only when a process starts up, or they inherit it from a parent process 🙃 So existing processes on a client may ignore a timezone change returned from the server 😵 Sometimes it's normal and expected for processes on the same client to have different timezone settings (e.g., remote logins) 🌏 So client implementations should consider these ramifications when they change the timezone settings of existing processes 🫠

7. The New Timezone Option and Lease Times ⏰

When a lease has expired and no new information is coming, the client MAY keep using the timezone information it got from the server 🥰 This follows the principle of least astonishment ✨

8. Deprecation of Time Offset Option 🌸

Okay bestie, so this new option does everything the old IPv4 time offset option (tag 2) did, and then some 💅. To keep IPv4 and IPv6 consistent, the older one is officially deprecated 🥀. Current implementations that support the time offset IPv4 option SHOULD implement this option also. Other implementations SHOULD implement this option, and SHOULD NOT implement the time offset IPv4 option. For the transition, clients that already use the time offset option MAY request the time offset option and the timezone option too ✨.

9. Security Considerations 🚨

An attacker could feed a client wrong information 😭. Someone might miss a meeting or show up early, or heavy machinery or other critical functions might act at the wrong time or fail to act at all 💀. If clients run job tools like cron, which work off wall clock time, certain jobs could fire too early or too late. They could even get repeated or skipped completely if they're scheduled during a DST transition 🙈. In cases like this, the client operating system might do well to confirm timezone changes with a human 🫶.

Clients using the POSIX option should beware of any time zone setting that has unusual characters (for example, control characters) in the standard or daylight-saving abbreviations. That can totally trigger security-relevant bugs in applications 👀.

Clients using the POSIX option should also be suspicious of any timezone setting whose UTC offset is more than 25 hours. That's the POSIX limit if the default daylight-saving offset is used 🧐. As of this writing, the maximum UTC offset is 14 hours in practice, but governments may extend that a bit in the future 🌍.

10. IANA Considerations 📋

The IANA has allocated DHCPv4 and DHCPv6 option codes for this purpose, and it references this document 🎀.

The IANA has annotated the time offset IPv4 option (tag 2) as deprecated, with a reference to this document 🥀.

11. Acknowledgments 💜

This document specifies a way to exchange timezone information. The hard part is honestly collecting changes to the various databases from scattered sources all around the world 🌏. The many volunteers on the mailing list tz@elsie.nci.nih.gov have done this nearly thankless task for many years, and they deserve all the flowers 💐. Thanks also go to Ralph Droms, Bernie Volz, Ted Lemon, Lisa Dusseault, John Hawkinson, Stig Venaas, and Simon Vaillancourt for their efforts to improve this work 🫶✨.

12. References 📚

12.1. Normative References

  • [1] "Standard for Information Technology - Portable Operating System Interface (POSIX) - Base Definitions", IEEE Std 1003.1-2004, December 2004.
  • [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
  • [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
  • [6] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
  • [7] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight Saving Time Data", <http://www.twinsun.com/tz/tz-link.htm>.

12.2. Informational References

Authors' Addresses 🖋️

Eliot Lear
Cisco Systems GmbH
Glatt-com
Glattzentrum, ZH  CH-8301
Switzerland

Phone: +41 1 878 9200
EMail: lear@cisco.com


Paul Eggert
UCLA
Computer Science Department
4532J Boelter Hall
Los Angeles, CA  90095
USA

Phone: +1 310 825 3886
EMail: eggert@cs.ucla.edu

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from