Network Working Group E. Lear
Internet-Draft Cisco Systems GmbH
Expires: July 29, 2006 January 25, 2006
A Timezone Option for DHcP
draft-lear-dhc-timezone-option-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 29, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
DHCP defines an option for a server to deliver to a client offset
from UTC. This information in and of itself is not sufficient for
devices to portray local time both accurately and consistently. This
memo specifies a new option for both DHCPv4 and DHCPv6 to do so.
1. Introduction
Dynamic Host Configuration Protocol (DHCP) [2] provides a means for
Lear Expires July 29, 2006 [Page 1]
Internet-Draft A Timezone option for DHCP January 2006
hosts to receive configuration information relating to their current
location within the network. RFC2132 [3] specifies an option to
provide a client timezone information in the form of an offset in
seconds from UTC. The information provided in this option is
insufficient for the client to determine whether it is in daylight
savings time and when to change into and out of daylight savings time
(DST). 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.
This memo specifies a means to provide hosts with more accurate
timezone information than was previously available. There are
currently three well known means to configure timezones:
o POSIX TZ strings
o Reference to the Olson Database
o Microsoft's timezone.xml
POSIX [1] provides a standard for how to express timezone information
in a character string. Use of such a string can provide forward and
backward accuracy for a total of one year. For backward accuracy
beyond a year a more detailed mechanism is necessary. The so-called
"Olson database" [5] that is used in many operating systems provides
backwards consistency and accuracy. The Olson database also attempts
to provide a stable set of human readable timezone identifiers. The
Microsoft TimeZone element conveys information similar to the POSIX
string, but with additional (presumably localized) display string.
2. New Timezone Option for DHCPv4
Code Len TZ Option 1 TZ Option N
+-----+-----+------------+-...-+-----------+
| TBD | N | . . |
+-----+-----+------------+-...-+-----------+
Code is TBD and will be allocated by IANA according to RFC-2939 [4].
Len is the two-octet sum of the size of all following TZ options.
Suboptions are described later in this document.
3. New Timezone Option for DHCPv6
Lear Expires July 29, 2006 [Page 2]
Internet-Draft A Timezone option for DHCP January 2006
The semantics and content of the DHCPv6 encoding of this option are
exactly the same as the encoding described in the previous section,
other than necessary differences between the way options are encoded
in DHCPv4 and DHCPv6.
Specifically, the DHCPv6 new timezone option has the following
format:
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_TIMEZONE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Timezone Suboptions |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NEW_TIMEZONE(TBD)
option-length: variable based on the number and value of suboptions.
4. The POSIX Suboption String
Suboption
number Len POSIX String
+---------+-----+--------------+
| 1 | N | |
+---------+-----+--------------+
Suboption number is an octet with a value of 1.
Len is the two-octet size of the following string.
POSIX string is a string suitable for the TZ variable as specified by
IEEE-1003.1-2004 Section 8.3. An example might be
"EST5EDT4,M4.1.1,M11.1.1". In this case, the string is interpretted
as a timezone with display name "EST" which is normally five hours
behind UTC, and hours behind UTC during DST, which runs from the
first Sunday in April through the first Sunday in November.
Clients and servers implementing the timezone option MUST support
this suboption.
Lear Expires July 29, 2006 [Page 3]
Internet-Draft A Timezone option for DHCP January 2006
5. The Olson Database Suboption
Suboption
number Len TZ Name
+---------+-----+--------------+
| 2 | N | |
+---------+-----+--------------+
Suboption number is an octet with a value of 2.
Len is the two-octet size of the following string.
TZ Name is an index to the database commonly referred to as the Olson
Timezone database. In order for this option to be useful the client
must already have a copy of the database. An example string would be
"Europe/Zurich".
If a client understands this option but does not recognize the TZ
Name returned, it MUST ignore this option and MAY make use of the
POSIX string.
6. The Microsoft TZ Suboption
Suboption
number TZ ID
+---------+-------------------+
| 3 | NNNN |
+---------+-------------------+
Suboption number is an octet with a value of 3.
TZ ID is a four-octet integer in network byte order that references
the timezone ID as defined in the TimeZone element, as specified by
Microsoft [6].
If a client does not have an entry corresponding to the TZ ID
returned by the server, the client MUST ignore this sub-option, and
MAY instead make use of the POSIX option.
7. Use of the timezone string returned from the server
This specification presumes the DHCP server has some means of
Lear Expires July 29, 2006 [Page 4]
Internet-Draft A Timezone option for DHCP January 2006
identifying which timezone the client is in. One obvious approach
would be to associate a subnet or group of subnets with a timezone,
and respond with this option accordingly.
The client uses this information at its discretion to configure the
current timezone in which it resides. This memo does not define
client behavior, particularly should it request and receive a
response with this option from multiple subnets where the timezone
information conflicts.
When a POSIX string is used, it will periodically be necessary for a
DHCP server to update the timezone string, based on administrative
changes made by local jurisdictions (say, for instance, counties in
Indiana). While the author does not expect this to be a lower bound
on a lease time in the vast majority of cases, there may be times
when anticipation of a change dictates prudence, as certain
governments give little if any notification.
8. The New Timezone Option and Lease times
When a lease has expired and new information is not forthcoming, the
client MAY continue to use timezone information returned by the
server. This follows the principle of least astonishment.
9. Security Considerations
It is unclear what trouble an attacker could cause by providing
erronious information to a client. It is possible that someone might
miss a meeting or otherwise show up early. If clients have job
processing tools such as cron that operate on wall clock time it is
possible that certain jobs could be triggered either earlier or
later. In such cases, the client operating system might do well to
confirm timezone changes with a human.
10. IANA Considerations
The IANA is requested to allocate both DHCPv4 and DHCPv6 option codes
for this purpose and reference this document in that allocation for
both DHCPv4 and DHCPv6.
The IANA need not and should not retain a list of suboptions. Any
new suboptions require further standards action.
Lear Expires July 29, 2006 [Page 5]
Internet-Draft A Timezone option for DHCP January 2006
11. Normative References
[1] "Standord for Information Technology - Portable Operating System
Interface", IEEE 1003.1-2004, December 2004.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[4] Droms, R., "Procedures and IANA Guidelines for Definition of New
DHCP Options and Message Types", BCP 43, RFC 2939,
September 2000.
[5] <http://elsie.nci.nih.gov>
[6] <http://msdn.microsoft.com/library/default.asp?url=/library/
en-us/spptsdk/html/tscamltimezone_sv01028158.asp>
Appendix A. Changes
o initial revision
Lear Expires July 29, 2006 [Page 6]
Internet-Draft A Timezone option for DHCP January 2006
Author's Address
Eliot Lear
Cisco Systems GmbH
Glatt-com
Glattzentrum, ZH CH-8301
Switzerland
Phone: +41 1 878 7525
Email: lear@cisco.com
Lear Expires July 29, 2006 [Page 7]
Internet-Draft A Timezone option for DHCP January 2006
Intellectual Property Statement
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; nor does it 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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lear Expires July 29, 2006 [Page 8]