Timezone Options for DHCP
RFC 4833
| Document | Type |
RFC - Proposed Standard
(April 2007; No errata)
Updates RFC 2132
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Replaces | draft-lear-dhc-timezone-option | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4833 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Jari Arkko | ||
| Send notices to | (None) | ||
Network Working Group E. Lear
Request for Comments: 4833 Cisco Systems GmbH
Updates: 2132 P. Eggert
Category: Standards Track UCLA
April 2007
Timezone Options for DHCP
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Two common ways to communicate timezone information are POSIX 1003.1
timezone strings and timezone database names. This memo specifies
DHCP options for each of those methods. The DHCPv4 time offset
option is deprecated.
Lear & Eggert Standards Track [Page 1]
RFC 4833 Timezone Options for DHCP April 2007
1. Introduction
This memo specifies a means to provide hosts with more accurate
timezone information than was previously available. To do this we
make use of two commonly used methods to configure timezones:
o POSIX TZ strings
o Reference to the name of the time zone entry in the TZ Database
POSIX [1] provides a standard for how to express timezone information
in a character string. Use of such a string can provide accuracy for
at least one transition into and out of daylight saving time (DST),
and possibly for more transitions if the transitions are regular
enough (e.g., "second Sunday in March at 02:00 local time").
However, for accuracy over longer periods that involve daylight-
saving rule changes or other irregular changes, a more detailed
mechanism is necessary.
The TZ Database [7] that is used in many operating systems provides
backwards consistency and accuracy for almost all real-world
locations since 1970. The TZ database also attempts to provide a
stable set of human readable timezone identifiers. In addition, many
systems already make use of the TZ database, and so the names used
are a de facto standard. Because the TZ database contains more
information, one can heuristically derive the POSIX information from
a TZ identifier (see [10] for an example), but the converse is not
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].
1.1. Related Work
Dynamic Host Configuration Protocol (DHCP) [3] provides a means for
hosts to receive configuration information relating to their current
location within an IP version 4 network. [5] similarly does so for IP
version 6 networks. RFC 2132 [4] specifies an option to provide
client timezone information in the form of an offset in seconds from
UTC. The information provided in that option is insufficient for the
client to determine whether it is in daylight saving time, and when
to change into and out of daylight saving time. In order for the
client to properly represent local wall clock time in a consistent
and accurate fashion the DHCP server would have to time lease
expirations of affected clients to the beginning or end of DST, thus
effecting a self stress test (to say the least) at the appointed
hour.
Lear & Eggert Standards Track [Page 2]
RFC 4833 Timezone Options for DHCP April 2007
In addition, an offset is not sufficient to determine the actual
timezone in which a client resides, and thus there is no means to
derive a human readable abbreviation such as "EST" or "EDT".
VTIMEZONE elements are defined in the iCalendar specification [9].
Fully specified they provide a level of accuracy similar to the TZ
database. However, because there is currently no global registry of
VTIMEZONE TZIDs (although one has been proposed; see [8]), complete
accuracy requires that a full entry must be specified. To achieve
the same information would range from 300 octets upwards with no
particular bound. Furthermore, at the time of this writing the
authors are aware of no operating system that natively takes
advantage of VTIMEZONE entries. It might be possible to include an
Show full document text