Groupe de travail Réseau	E. Lear, Cisco Systems GmbH	
Request for Comments : 4833	P. Eggert, UCLA	
RFC mise à jour : 2132	avril 2007	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Options de zone horaire pour DHCP

Statut du présent mémoire
Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se rapporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD  1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Déclaration de copyright
Copyright (C) The IETF Trust (2007).

Résumé
Deux façons courantes de communiquer les informations de zone horaire sont les chaînes de zone horaire POSIX 1003.1 et les noms de base de données de zone horaire. Le présent mémoire spécifie les options DHCP pour chacune de ces méthodes. L'option de décalage horaire de DHCPv4 est déconseillée.
Table des matières
1. Introduction	1
1.1 Travaux connexes	2
2. Nouvelles options Timezone pour DHCPv4	2
3. Nouvelles options Timezone pour DHCPv6	2
4. Chaîne POSIX TZ	3
5. Nom de zone horaire	3
6. Utilisation des chaînes Timezone retournées du serveur	3
7. Nouvelle option Timezone et temps de prêt	4
8. L'option Time Offset est déconseillée	4
9. Considérations pour la sécurité	4
10. Considérations relatives à l'IANA	5
11 Remerciements	5
12. Références	5
12.1 Références normatives	5
12.2 Références pour information	5
Adresse des auteurs	6
Déclaration complète de droits de reproduction	6
 	1.	Introduction

Le présent mémoire spécifie un moyen pour fournir aux hôtes des informations de zone horaire plus précises que ce qui était précédemment disponible. Pour ce faire, on utilise deux méthodes d'utilisation courante pour configurer les zones horaires :
o	des chaînes TZ POSIX
o	une référence au nom de l'entrée de zone horaire dans la base de données TZ.

POSIX [POSIX] fournit une norme sur la façon d'exprimer les informations de zone horaire dans une chaîne de caractères. L'utilisation d'une telle chaîne peut fournir une précisison pour au moins une transition dans les passages de et à l'heure d'été (DST, daylight saving time) et éventuellement pour plus de transitions si elles sont assez régulières (par exemple, "le second dimanche de mars à 02:00 en heure locale"). Cependant, pour une précision sur des périodes plus longues qui impliquent des changements de règle de passage à l'heure d'été ou autres changements irréguliers, un mécanisme plus détaillé est nécessaire.

La base de données TZ [TimeZone] qui est utilisée dans de nombreux systèmes d'exploitation assure une cohérence et une précision pour la plupart des localisation réelles depuis 1970. La base de données TZ tente aussi de fournir un ensemble stable d'identifiants de zone horaire lisibles par l'homme. De plus, de nombreux systèmes utilisent déjà la base de données TZ, et donc les noms utilisés sont un standard de fait. Parce que la base de données TZ contient plus d'informations, on peut déduire de façon heuristique les informations POSIX d'un identifiant TZ (voir un exemple dans [Calendar]) mais l'inverse n'est pas vrai.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la RFC 2119 [RFC2119].

 	1.1	Travaux connexes
Le protocole de configuration dynamique d'hôte (DHCP, Dynamic Host Configuration Protocol) [RFC2131] fournit un moyen pour que les hôtes reçoivent des informations de configuration relatives à leur localisation actuelle dans un réseau IP version 4. La [RFC3315] fait la même chose pour les réseaux IP version 6. La [RFC2132] spécifie une option pour fournir au client les informations de zone hairaire sous la forme d'un décalage en secondes par rapport à l'UTC. Les informations fournies dans cette option sont insuffisantes pour que le client détermine si il est dans l'heure d'été, et quand changer pour passer à et de l'heure d'hiver à l'heure d'été. Afin que le client représente correctement l'heure locale d'une façon cohérente et précise, le serveur DHCP va devoir mesurer les expirations de prêt des clients affectés au début ou à la fin du DST, donc d'effectuer un auto essai (pour le moins) à l'heure décidée.

De plus, un décalage n'est pas suffisant pour déterminer la zone horaire réelle dans laquelle réside un client, et donc il n'y a pas de moyen pour déduire une abréviation lisible par l'homme comme "EST" ou "EDT".

Des éléments VTIMEZONE sont définis dans la spécification iCalendar [RFC2445]. Pleinement spécifiés, ils fournissent un niveau de précision similaire à celui de la base de données TZ. Cependant, parce qu'il n'y a pas actuellement de registre mondial des identifiants de TZ VTIMEZONE (bien qu'il en ait été proposé un ; voir [Rec]) une précision complète exige qu'une entrée complète soit spécifiée. Pour réaliser la même information il faudrait au moins 300 octets sans limite supérieure particulière. De plus, au moment de la rédaction du présent mémoire, les auteurs ne connaissent pas de système d'exploitation qui tire naturellement parti des entrées de VTIMEZONE. Il serait possible d'inclure une option pour un TZURL. Cependant, dans un environnement de démarrage à froid, il serait assez mauvais que les appareils fassent peser cette charge sur le serveur DHCP, et peut-être malavisé de peser de façon similaire sur les autres composants.

 	2.	Nouvelles options Timezone pour DHCPv4

Les deux options suivantes sont définies pour DHCPv4 :

 PCode  Long  Chaîne TZ-POSIX
+-----+-----+------------------------------+
| 100 |  N  | chaîne IEEE 1003.1           |
+-----+-----+------------------------------+

 TCode  Long  Chaîne de base de données TZ
+-----+-----+------------------------------+
| 101 |  N  | Référence à la B. de d. TZ   |
+-----+-----+------------------------------+

Selon la [RFC2939], l'IANA a alloué le PCode (100) et le TCode (101).

Long est la valeur de un octet de la longueur de la chaîne qui suit pour chaque option.

Les valeurs de chaîne qui suivent Long sont décrites ci-dessous. Noter qu'elles NE SONT PAS terminées par un NUL ASCII.

 	3.	Nouvelles options Timezone pour DHCPv6

La sémantique et le contenu du codage DHCPv6 de ces options sont exactement les mêmes que le codage décrit pour DHCPv4, autre que les nécessaires différences entre la façon dont les options sont codées dans DHCPv4 et DHCPv6.

Précisément, les options de nouvelle zone horaire DHCPv6 sont décrites ci-dessous :

 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    |       Longueur d'option       |
+---------------+---------------+---------------+---------------+
|                     Chaîne TZ POSIX                           |
|                              ...                              |
+---------------+---------------+---------------+---------------+

Code d'option : OPTION_NEW_POSIX_TIMEZONE(41)

Longueur d'option : nombre d'octets de l'indice de chaîne TZ POSIX décrit ci-dessous.

 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    |        Longueur d'option       |
+---------------+---------------+---------------+---------------+
|                        Nom de la zone horaire                 |
+---------------+---------------+---------------+---------------+

Code d'option : OPTION_NEW_TZDB_TIMEZONE(42)

Longueur d'option : nombre d'octets de l'indice de chaîne de base de données TZ décrit ci-dessous.

 	4.	Chaîne POSIX TZ

La chaîne TZ POSIX est une chaîne qui convient pour la variable TZ telle que spécifiée au paragraphe 8.3 de [POSIX], à l'exception qu'une chaîne ne doit pas commencer par deux points (":"). Cette chaîne N'EST PAS terminée par un NUL ASCII. Voici un example :

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

Dans ce cas, la chaîne est interprétée comme une zone horaire qui est normalement cinq heures après l'UTC, et quatre heures après l'UTC durant le DST, qui va du second dimanche de mars à 02:00, heure locale, jusqu'au premier dimanche de novembre à 02:00 heure locale. Normalement la zone horaire est abrégée en "EST" mais durant le DST elle est abrégée en "EDT".

Les clients et serveurs qui mettent en œuve d'autres options de zone horaire DOIVENT prendre en charge cette option pour la compatibilité de base.

 	5.	Nom de zone horaire

Le nom de zone horaire (TZ, Time Zone) est le nom d'une entrée de zone dans la base de donnnées couramment appelée la base de donnes TZ. Spécifiquement, dans la forme textuelle de la base de données, la chaîne se réfère au champ Nom d'une ligne de zone. Afin que cette option soit utile, le client doit toujours avoir une copie de la base de données. Cette chaîne N'EST PAS terminée par un NUL ASCII.

Un exemple de chaîne est Europe/Zurich.

Les clients doivent toujours avoir une copie de la base de données TZ pour que cette option soit utile. La configuration de la base de données sort du domaine d'application du présent document. Un client qui prend en charge cette option DEVRAIT préférer cette option à la chaîne POSIX si il reconnaît le nom de TZ qui a été retourné. Si il ne reconnaît pas le nom de TZ, le client DOIT ignorer cette option.

 	6.	Utilisation des chaînes Timezone retournées du serveur

La présente spécification présuppose que le serveur DHCP a des moyens d'identifer dans quelle zone horaire se trouve le client. Une approche évidente serait d'associer un sous réseau ou un groupe de sous réseaux à une zone horaire, et de répondre en conséquence à cette option.

Quand on considère quelle option mettre en œuvre sur un client, on doit choisir entre le nom de TZ, qui devrait être plus facile à configurer pour les utilisateurs et qui fournit la précision sur de plus longues périodes historiques, et la chaîne TZ POSIX, qui n'exige pas de mise à jour régulière d'une copie de la base de données TZ. Le nom de TZ est mieux pour la plupart des utilisations, en particulier dans les cas où le nom de la zone horaire pourrait persister dans une base de données pendant de longues périodes, mais la chaîne TZ POSIX peut être plus convenable pour des applications de petites empreintes qui sont tenues par des mains expertes.

Afin que les clients n'aient pas besoin de demander les deux options, les serveurs qui mettent en œuvre l'une des deux options de zone horaire DEVRAIENT mettre aussi en œuvre l'autre. Cette association peut être établie par l'administrateur du serveur. Un serveur de base peut transmettre les valeurs d'option au client sans les analyser ou les valider. Un serveur plus évolué pourrait avoir une copie de la base de données de TZ et valider les noms de TZ par rapport à cette copie, ou déduire les chaînes TZ POSIX de façon heuristique à partir des noms de TZ pour simplifier l'administration.

D'un point de vue pratique, le client va utiliser ces informations à sa discrétion pour configurer la zone horaire actuelle dans laquelle il réside.

Il va être périodiquement nécessaire qu'un serveur DHCP mette à jour la chaîne de zone horaire, sur la base des changements administratifs faits par les juridictions locales (disons, par exemple, des comtés en Indiana). Bien que les auteurs ne croient pas que ce soit une limite inférieure au temps de prêt dans la vaste majorité des cas, il peut y avoir des cas où l'anticipation d'un changement impose la prudence, car certains gouvernements font peu de notifications sinon pas du tout.

L'effet d'un changement de zone horaire sur les applications d'un client n'est pas spécifié par le présent mémoire, mais il peut être utile de noter les problèmes courants dans ce domaine. Souvent, les applications de client consultent les réglages de zone horaire seulement durant l'initialisation des processus, ou héritent du réglage d'un processus parent, de sorte que les processus existants sur un client peuvent ignorer un changement de zone horaire retourné du serveur. Parfois, il est normal et attendu que les processus sur le même client aient des réglages de zone horaire différents (par exemple, pour les connexions à distance) et donc les mises en œuvre de client devraient considérer les implications d'un changement de réglage de zone horaire des processus existants.

 	7.	Nouvelle option Timezone et temps de prêt

Quand un prêt est arrivé à expiration et que de nouvelles informations n'arrivent pas, le client PEUT continuer d'utiliser les informations de zone horaire retournées par le serveur. Ceci suit le principe de moindre étonnement.

 	8.	L'option Time Offset est déconseillée

Parce que cette option fournit un sur ensemble de fonctionnalités sur l'option précédente de décalage de temps IPv4 (étiquette 2) et afin de conserver la cohérence entre les mises en œuvre de IPv4 et de IPv6, l'ancienne option est déconseillée. Les mises en œuvre actuelles qui prennent en charge l'option IPv4 de décalage de temps DEVRAIENT aussi mettre en œuvre cette option. Les autres mises en œuvre DEVRAIENT prendre en charge cette option, et NE DEVRAIENT PAS mettre en œuvre l'option IPv4 de décalage de temps. À titre de transition, les clients qui utilisent déjà l'option de décalage de temps PEUVENT demander l'option de décalage de temps et l'option de zone horaire.

 	9.	Considérations pour la sécurité

Un attaquant pourrait fournir des informations erronées à un client. Il est possible que quelqu'un puisse manquer une réunion ou autrement s'y présenter trop tôt, ou qu'une machinerie lourde ou autres fonctions critiques puissent agir au mauvais moment ou ne pas se mettre en marche. Si les clients ont des outils de traitement de tâches, comme un chronomètre qui fonctionne sur l'heure de l'horloge, il est possible que certaines tâches soient déclenchées trop tôt ou trop tard, ou même empêchées ou sautées entièrement si elles sont programmées durant une transition de DST. Dans de pareils cas, le système d'exploitation du client ferait bien de confirmer les changements de zone horaire auprès d'un humain.

Les clients qui utilisent l'option POSIX devraient se méfier de tout réglage de zone horaire qui spécifie des caractères inhabituels (par exemple, des caractères de contrôle) dans les abréviations de l'heure standard ou de l'heure d'été, car elles pourraient bien déclencher des fautes relevant de la sécurité dans les applications.

Les clients qui utilisent l'option POSIX devraient aussi être méfiants à l'égard de tout réglage de zone horaire dont le décalage à l'UTC excède 25 heures (la limite POSIX, si le décalage par défaut de l'heure d'été est utilisé). Au moment de la présente rédaction, le décalage maximum à l'UTC est de 14 heures en pratique, mais des gouvernements pourraient étendre un peu cela à l'avenir.

 	10.	Considérations relatives à l'IANA

L'IANA a alloué les codes d'option DHCPv4 et DHCPv6 pour cet objet et fait référence au présent document.

L'IANA a annoté l'option IPv4 de décalage horaire (tag 2) comme déconseillée, avec une référence au présent document.

 	11	Remerciements

Le présent document spécifie un moyen pour échanger des informations de zone horaire. La partie difficile est de collecter les changements réels sur les diverses bases de données à partir de sources éparpillées tout autour du monde. Les nombreux volontaires de la liste de diffusion tz@elsie.nci.nih.gov ont accompli bénévolement cette tâche pendant de nombreuses années. Merci aussi à Ralph Droms, Bernie Volz, Ted Lemon, Lisa Dusseault, John Hawkinson, Stig Venaas et Simon Vaillancourt pour leurs efforts d'amélioration de ce travail.

 	12.	Références
 	12.1	Références normatives

[POSIX]	"Standard for Information Technology - Portable Operating System Interface (POSIX) - Base Definitions", IEEE Std 1003.1-2004, décembre 2004.

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2132]	S. Alexander et R. Droms, "Options DHCP et Extensions de fabricant BOOTP", mars 1997.

[RFC2133]	R. Gilligan et autres, "Extensions d'interface de prise de base pour IPv6", avril 1997. (Obsolète, voir RFC2553) (Info.)

[RFC2939]	R. Droms, "Procédures et lignes directrices pour l'IANA pour la définition de nouvelles options et types de message DHCP", BCP 43, septembre 2000.

[RFC2939]	R. Droms, "Procédures et lignes directrices pour l'IANA pour la définition de nouvelles options et types de message DHCP", BCP 43, septembre 2000.

[RFC3315]	R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins et M. Carney, "Protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)", juillet 2003. (MàJ par RFC6422,  RFC6644, RFC7227 ; obsolète voir RFC8415)

[TimeZone]	Eggert, P. and A. Olson, "Sources for Time Zone and Daylight Saving Time Data", <http://www.twinsun.com/tz/tz-link.htm >.

 	12.2	Références pour information

[Calendar]	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 >.

[Rec]	Vaillancourt, S., "Calconnect.org TC Timezone Technical Committee: Timezone Registry and Service Recommendations", avril 2006.

[RFC2445]	F. Dawson et D. Stenerson, "Spécification centrale des objets de calendrier et de programmation de l'Internet (iCalendar)", novembre 1998. (P.S., Obsolète, voir RFC5545)

 	Adresse des auteurs

Eliot Lear	Paul Eggert	
Cisco Systems GmbH	UCLA	
Glatt-com	Computer Science Department	
Glattzentrum, ZH  CH-8301	4532J Boelter Hall	
Switzerland	Los Angeles, CA  90095	
	USA	
téléphone : +41 1 878 9200	téléphone : +1 310 825 3886	
mél : lear@cisco.com 	mél : eggert@cs.ucla.edu 	

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2007).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org .

Remerciement 
Le financement de la fonction d’édition des RFC est actuellement fourni par l’activité de soutien administratif (IASA) de l’IETF.