Timezone Options for DHCP
RFC 4833

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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
   option for a TZURL.  However, in a cold start environment, it will be
   bad enough that devices are stressing the DHCP server, and perhaps
   unwise to similarly afflict other components.

2.  New Timezone Options for DHCPv4

   The following two options are defined for DHCPv4: