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
Статус документа
Это документ содержит проект стандарта протокола 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
Перевод на русский язык
Николай Малых
Полное заявление авторских прав
Copyright (C) The IETF Trust (2007).
К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Интеллектуальная собственность
IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.
IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
1Daylight saving time.
2Dynamic Host Configuration Protocol — протокол динамической настройки конфигурации.