RFC4833 Timezone Options for DHCP

Please enter banners and links.

image_print
Network Working Group                                            E. Lear
Request for Comments: 4833                            Cisco Systems GmbH
Updates: 2132                                                  P. Eggert
Category: Standards Track                                           UCLA
                                                              April 2007

Опции часового пояса для DHCP

Timezone Options for DHCP

PDF

Статус документа

Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Распространение документа не ограничивается.

Авторские права

Copyright (C) The IETF Trust (2007).

Тезисы

Двумя основными способами обмена информацией о часовых поясах являются строки POSIX 1003.1 timezone и имена в базе данных timezone. Этот документ задает опции DHCP для каждого из этих методов. Использование опции DHCPv4 time offset прекращается.

1. Введение

Этот документ задает способ предоставления хостам более точной информации о часовом поясе, нежели было возможно раньше. Для этого используются два общепринятых метода настройки часового пояса:

  • POSIX-строка TZ;

  • ссылка на имя записи для часового пояса в базе данных TZ.

Стандарт POSIX [1] обеспечивает способ представления часового пояса в форме строки. Использование таких строк позволяет осуществлять точный переход между летним и зимним временем (DST1), а также другие случаи перевода часов, которые происходят регулярно (например, во второе воскресенье марта в 02:00 по местному времени). Однако для переходов с более длительными периодами, которые включают изменение правил перехода на летнее время, я также для нерегулярных переходов требуются другие механизмы.

База данных TZ [7], используемая во многих операционных системах, обеспечивает совместимость со старыми версиями, а также требуемую точность перехода для большинства мест планеты и времени с 1970 года. База данных TZ таже пытается обеспечить понятный для человека набор идентификаторов часовых поясов. Кроме того, многие системы уже используют базу данных TZ и имена часовых поясов стали фактически стандартными. Поскольку база данных TZ содержит больше информации, можно эвристически вывести информацию POSIX из идентификатора TZ (см., например, [10]), но не наоборот.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [2].

1.1. Смежные работы

Протокол DHCP2 [3] обеспечивает хостам возможность получения конфигурационной информации, относящейся к конкретному местоположению в сети IP сервии 4. Аналогично поддерживается и настройка хостов IP версии 6 [5]. В RFC 2132 [4] задана опция для предоставления клиенту информации о часовом поясе в форме смещения относительно времени UTC в секундах. Предоставляемой этой опцией информации не достаточно для определения клиентом настроек летнего времени и перехода между летним и зимним временем. Для того, чтобы клиент мог точно установить местное время, серверам DHCP следует учитывать переход DST при определении срока действия аренды.

Кроме того, смещения недостаточно для определения реального часового пояса, к которому относится клиент, и в результате нет возможности получить понятное человеку обозначение часового пояса типа EST или EDT.

В спецификации iCalendar [9] определены элементы VTIMEZONE. При полном задании они обеспечивают уровень точности, схожий с базой данных TZ. Однако по причине отсутствия глобального реестра VTIMEZONE TZID (хотя один из возможных реестров предложен в [8]) для точного указания часового пояса требуется указать запись полностью. Для обеспечения нужной информации потребуется не менее 300 октетов, а верхней границы просто нет. Кроме того, на момент подготовки этого документа авторам не было известно ни одной операционной системы, изначально использующей записи VTIMEZONE. Можно включить опцию для TZURL. Однако при «холодном старте» это будет сильно нагружать серверы DHCP и другие компоненты.

2. Новые опции часового пояса для DHCPv4

Ниже показаны две новых опции, определенные для протокола DHCPv4.

            PCode  Len   TZ-POSIX String
           +-----+-----+------------------------------+
           | 100 |  N  | Строка IEEE 1003.1           |
           +-----+-----+------------------------------+

            TCode  Len   TZ-Database String
           +-----+-----+------------------------------+
           | 101 |  N  | Ссылка на TZ Database        |
           +-----+-----+------------------------------+

В соответствии с RFC 2939 [6] агентство IANA выделило значения PCode (100) и TCode (101).

Поле Len содержит 1-октетное значение, которое указывает размер следующей за полем строки в каждой из опций.

Значения строк, следующих за полем Len описаны ниже. Отметим, что они не завершаются символом ASCII NULL.

3. Новые опции часового пояса для DHCPv6

Семантика и содержимое представления этих опций в DHCPv6 в точности совпадают с описанными для DHCPv4 с учетом различий в способах кодирования опций DHCPv4 и DHCPv6.

Представление новых опций часового пояса в DHCPv6 показано ниже.

       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

Число октетов TZ POSIX String, описанной ниже.

       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

Число октетов TZ Database String, описанной ниже.

4. POSIX-строка TZ

POSIX-строка TZ представляет собой строку, подходящую для переменной TZ, в соответствии с параграфом 8.3 [1] за исключением того, что эта строка не должна начинаться с двоеточия (:). Строка не завершается символом ASCII NULL. Пример строки приведен ниже.

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

Эта строка описывает часовой пояс, отстающий от UTC на 5 часов в обычный период (зимой) и на 4 в период DST (летом), который начинается во второе воскресенье марта в 02:00 по местному времени и заканчивается в первое воскресенье ноября в 02:00 по местному времени. В обычный период этот часовой пояс обзначается EST, а в период DST – EDT.

Клиенты и серверы, реализующие другие опции часового пояса, должны поддерживать эту опцию для базовой совместимости.

5. TZ Name

TZ Name представляет собой имя записи Zone в базе данных, которую обычно называют базой данных TZ. В частности, при текстовом формате базы данных строка указывает поле name в строке часового пояса. Для использования этой опции у клиента должна быть копия базы данных. Строка не завершается символом ASCII NULL.

Примером может служить строка Europe/Zurich.

Для использования этой опции у клиента уже должна быть копия TZ Database. Конфигурация базы данных выходит за рамки этого документа. Клиентам, поддерживающим эту опцию, следует предпочитать ее строке POSIX, если он распознает возвращенную строку TZ Name. Если строка TZ Name не распознана, клиент должен игнорировать опцию.

6. Использование строк, возвращенных сервером

Данная спецификация предполагает, что у сервера DHCP имеется тот или иной способ определения часового пояса, в котором размещается клиент. Обычно с часовым поясом связывается подсеть или группа подсетей и клиентам из этих подсетей возвращается соответствующая информация.

При выборе опции, реализуемой на стороне клиента, должно приниматься во внимание что использование TZ Name проще и обеспечивает точность в течение продолжительных периодов, зато POSIX-строка TZ POSIX не требует регулярно обновлять копию базы данных TZ. Для большинства пользователей TZ Name будет лучше, в частности для случаев, когда часовой пояс не меняется в течение продолжительного времени, но POSIX-строка TZ может оказаться более удобной для небольших приложений с хорошей поддержкой.

От клиентов не требуется реализация обоих вариантов, а серверу, поддерживающему одну из этих опций, следует реализовать и другую. Связь между опциями может быть организована администратором системы. Базовый сервер может передавать клиентам значения опций без их анализа и проверки пригодности. Более функциональный сервер может иметь копию базы данных TZ и сравнивать значения TZ name с имеющейся копией или эвристически выводить POSIX-строки TZ из строк TZ name для упрощения администрирования.

На практике клиент будет применять полученную информацию по своему усмотрению для настройки часового пояса, в котором он размещен.

Сервер DHCP должен периодически обновлять строки часовых поясов с учетом административных изменений местных правовых актов (например, округов штата Indiana). Хотя авторы и не предполагают, что это будет нижней границей срока аренды в подавляющем большинстве случаев, возможны ситуации, когда ожидание изменений будет требовать осмотрительности, поскольку некоторые регуляторы не дают уведомлений совсем или дают их мало.

Влияние смены часового пояса на клиентские приложения не рассматривается в этом документе, но полезно будет отметить наличие связанных с этим проблем. Зачастую клиентские приложения устанавливают часовой пояс лишь в процесс инициализации или принимают настройки от родительского процесса, поэтому действующие на стороне клиента процессы могут игнорировать изменения часового пояса, полученные от сервера. Иногда процессы на одном клиенте могут использовать разные установки часовых поясов (например, при удаленном доступе), поэтому реализациям клиентов следует учитывать последствия смены часового пояса в действующих процессах.

7. Новая опция Timezone и время аренды

Когда срок аренды закончился и новой информации не поступило, клиент может продолжать использование часового пояса, возвращенного сервером. Это следует принципу «наименьших сюрпризов».

8. Отмена опции Time Offset

Поскольку эта опция обеспечивает надмножество функциональности прежней опции IPv4 time offset (тег 2) и для поддержки согласованности между реализациями IPv4 и IPv6 использование прежней опции отменяется. Имеющимся реализациям, которые поддерживают опцию time offset IPv4, следует реализовать также новую опцию. Другим реализациям следует поддерживать эту опцию и недопустимо реализовать опцию time offset IPv4. В процессе перехода клиенты, которые уже пользуются опцией time offset, могут запрашивать опции time offset и timezone.

9. Вопросы безопасности

Атакующий может предоставить клиенту ложную информацию. В результате кто-то может пропустить встречу или оказаться на ней слишком рано, а также возможно рассогласование работы сложной техники или выполнения иных важных функций и даже возникновение отказов в работе. Если у клиента имеются средства управления заданиями (например, cron), работающие по часам, возможно выполнение некоторых заданий раньше или позже запланированного времени, повтор или пропуск некоторых заданий во время перехода DST. В таких случаях может оказаться разумным запрос операционной системой подтверждения на изменение часового пояса от человека.

Клиентам, использующим опцию POSIX, следует остерегаться строк, содержащих необычные символы (например, коды управления) в сокращениях часового пояса, поскольку это может быть связано с ошибками в защите приложений.

Клиентам, использующим опцию POSIX, следует также с подозрением относиться к установкам часового пояса, задающим смещение от UTC более 25 часов (ограничение POSIX с учетом использования летнего времени). На момент подготовки этого документа максимальное смещение от UTC на практике составляло 14 часов, но в будущем это смещение может быть увеличено.

10. Взаимодействие с IANA

Агентство IANA выделило коды опций DHCPv4 и DHCPv6 для указания часового пояса со ссылками на этот документ.

Агентство IANA анонсировало отмену опции time offset IPv4 (тег 2) со ссылкой на этот документ.

11. Благодарности

Этот документ задает способ обмена информацией о часовых поясах. Сложно было собрать изменения различных баз данных из расположенных по всему миру источников. Многие добровольцы делали эту работу на протяжении нескольких лет через список рассылки tz@elsie.nci.nih.gov. Спасибо также Ralph Droms, Bernie Volz, Ted Lemon, Lisa Dusseault, John Hawkinson, Stig Venaas и Simon Vaillancourt за их вклад в улучшение этой работы.

12. Литература

12.1. Нормативные документы

[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. Дополнительная литература

[8] Vaillancourt, S., “Calconnect.org TC Timezone Technical Committee: Timezone Registry and Service Recommendations”, April 2006.

[9] Dawson, F. and Stenerson, D., “Internet Calendaring and Scheduling Core Object Specification (iCalendar)”, RFC 2445, November 1998.

[10] Eggert, P. and E. Reingold, “cal-dst.el — calendar functions for daylight savings rules”, <http://cvs.savannah.gnu.org/viewcvs/*checkout*/emacs/lisp/calendar/cal-dst.el?root=emacs>.

Адреса авторов

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

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

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.

Интеллектуальная собственность

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.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Daylight saving time.

2Dynamic Host Configuration Protocol — протокол динамической настройки конфигурации.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Or