Groupe de travail Réseau

T. Lemon, Nominum, Inc.

Request for Comments : 3396

S. Cheshire, Apple Computer, Inc.

RFC mise à jour : 2131

novembre 2002

Catégorie : En cours de normalisation

TraductionClaude Brière de L'Isle

 

 

 

Codage d'options longues
dans le protocole de configuration dynamique d'hôte (DHCPv4)

 

Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

 

Notice de copyright

Copyright (C) The Internet Society (2002). Tous droits réservés.

 

Résumé

Le présent document spécifie les règles de traitement des options du protocole de configuration dynamique d'hôte 'DHCPv4, Dynamic Host Configuration Protocol) qui apparaissent plusieurs fois dans le même message. Plusieurs instances de la même option sont générées lorsque une option excède la taille de 255 octets (taille maximum d'une seule option) ou lorsque une option a besoin d'être partagée afin de tirer parti de l'option DHCP Surcharge (overloading). Lorsque plusieurs instances de la même option apparaissent dans les options, fichiers et/ou champs sname dans un paquet DHCP, le contenu de ces options est concaténé pour former une seule option avant le traitement.

 

1.   Introduction

 

Le présent document met à jour la RFC 2131 [3] en précisant les règles de l'enchaînement d'options spécifiée au paragraphe 4.1. On suppose que le lecteur est familiarisé avec cette partie de la RFC 2131. Le texte du paragraphe 4.1 qui dit "Les options ne peuvent apparaître qu'une seule fois, sauf mention contraire dans le document sur les options." devrait être considéré comme supprimé.

 

Le protocole DHCP [3] spécifie les objets appelés "options" qui sont codés dans le paquet DHCPv4 pour passer les informations entre les agents de protocole DHCP. Ces options sont codées comme un code de type à un octet, une longueur d'un octet, et un tampon comportant le nombre d'octets spécifié dans la longueur, de zéro à 255.

 

Cependant dans certains cas, il peut être utile d'envoyer des options dont la longueur est supérieure à 255 octets. La RFC 2131 [3] spécifie que lorsque apparaît plus d'une option d'un code de type donné dans le paquet DHCP, toutes ces options devraient être enchaînées ensemble. Elle ne spécifie cependant pas l'ordre dans lequel devrait survenir cet enchaînement.

 

On spécifie ici l'ordre qui DOIT être utilisé par les agents de protocole DHCP lors de l'envoi d'options avec plus de 255 octets. Cette méthode DOIT aussi être utilisée pour étaler des options qui sont plus courtes que 255 octets, si pour une raison quelconque l'agent de codage a besoin de le faire. Les agents de protocole DHCP DOIVENT utiliser cette méthode chaque fois qu'ils reçoivent un paquet DHCP qui contient plus d'une occurrence d'un certain type d'option.

 

2.   Terminologie

 

DHCP

Dans tout ce document, l'acronyme "DHCP" est utilisé pour désigner le protocole de configuration dynamique d'hôte tel que spécifié dans la RFC 2131 [3] et la RFC 2132 [4].

 

DHCPv4

Le terme "DHCPv4" est utilisé dans le résumé du présent document pour faire la différence entre le protocole DHCP pour IPv4 tel que défini dans les RFC 2131 et RFC 2132 et le protocole DHCP pour IPv6, qui au moment de la rédaction du présent document, était encore en cours d'élaboration.

 

agents de protocole DHCP

Cela se réfère à tout appareil du réseau qui envoie ou reçoit des paquets DHCP – tout client, serveur ou agent de relais DHCP. La nature de ces appareils n'a pas d'importance dans la présente spécification.

 

agent de codage

C'est l'agent de protocole DHCP qui compose un paquet DHCP à envoyer.

 

agent de décodage

C'est l'agent de protocole DHCP qui traite un paquet DHCP qu'il a reçu.

 

options

Les options DHCP sont des collections de données avec des codes de type qui indiquent comment les options devraient être utilisées. Les options peuvent spécifier des informations qui sont exigées pour le protocole DHCP, des paramètres de configuration de la pile IP pour le client, des informations qui permettent au client de se donner rendez-vous avec des serveurs DHCP, et ainsi de suite.

 

surcharge d'option

Le format de paquet DHCP se fonde sur le format de paquet BOOTP défini dans la RFC 951 [1]. Lorsqu'ils sont utilisés par des agents de protocole DHCP, les paquets BOOTP ont trois champs qui peuvent contenir des options. Ce sont le champ paramètres facultatifs, le champ sname, et le champ filename. La spécification des options DHCP [4] définit l'option DHCP Overload (surcharge), qui spécifie lequel de ces trois champs est réellement utilisé dans tout message DHCP donné pour mémoriser les options DHCP.

 

3.   Exigences de langage

 

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, RFC 2119 [2].

 

4.   Applicabilité

 

La présente spécification s'applique lorsqu'un agent DHCP code un paquet qui contient des options, dont certaines doivent être divisées. Cela peut être nécessaire pour deux raisons. D'abord, cela peut arriver parce que la valeur d'une option qui doit être envoyée est plus longue que 255 octets. Dans ce cas, l'agent de codage DOIT suivre l'algorithme spécifié ici. Cela peut aussi survenir parce qu'il n'y a pas un espace suffisant dans la mémoire tampon de sortie actuelle pour mémoriser l'option, mais il y a de l'espace pour une partie de l'option, et il y a de l'espace dans une autre mémoire tampon de sortie pour le reste. Dans ce cas, l'agent de codage DOIT soit utiliser cet algorithme, soit ne pas envoyer du tout l'option.

 

La présente spécification s'applique aussi dans le cas où un agent de protocole DHCP a reçu un paquet DHCP qui contient plus d'une instance d'une option d'un type donné. Dans ce cas, l'agent DOIT concaténer ces différentes instances de la même option de la façon spécifiée ici.

 

Cette option met à jour les documents Protocole de configuration dynamique d'hôte [3] et Options DHCP et extensions de fabricant BOOTP [4]. Cependant, comme de nombreux agents de protocole DHCP actuellement en service ne mettent pas en œuvre la concaténation d'option, les agents de protocole DHCP devraient faire attention à ne transmettre d'options partagées que si cela n'a pas d'importance que le receveur ne puisse correctement réassembler les options, ou si il est certain que le receveur met en œuvre la concaténation.

 

Divisons toutes les options DHCP en deux catégories – celles qui, par définition, exigent la mise en œuvre des mécanismes définis dans le présent document, et celles qui ne le font pas. On appellera les premières options qui exigent l'enchaînement, et ces dernière, options qui n'exigent pas l'enchaînement. Pour qu'une option soit une de celles qui exigent l'enchaînement, la spécification du protocole qui définit cette option doit exiger la mise en œuvre du partage d'option et de l'enchaînement d'option telles que décrites dans le présent document, en s'y référant spécifiquement.

 

Un agent de protocole DHCP NE DEVRAIT partager une option comme décrit dans le présent document que s'il n'a pas d'autre choix ou s'il sait que son homologue peut correctement traiter les options partagées. Un homologue est supposer traiter correctement les options partagées si il a fourni ou demandé au moins un option qui exige l'enchaînement. Autrement, l'administrateur de l'agent qui génère l'option peut spécifiquement configurer l'agent pour qu'il suppose que le receveur peut correctement concaténer les options partagées comme décrit dans le présent document.

 

Certaines mises en œuvre pourront trouver plus facile de ne partager que les options qui exigent l'enchaînement, et de ne jamais partager les options qui n'exigent pas l'enchaînement. Cela est admissible. Cependant, une mise en œuvre qui prend en charge l'option qu'exige l'enchaînement DOIT être capable de concaténer les options reçues à la fois pour les options qui exigent l'enchaînement et pour celles qui ne l'exigent pas.

 

Aucune restriction ne s'applique à l'enchaînement d'option lorsque un agent DHCP reçoit un message DHCP. Tout agent de protocole DHCP qui met en œuvre les mécanismes décrits dans le présent document peut supposer que quand il reçoit deux options du même, il devrait les enchaîner.

 

5.   La mémoire tampon d'agrégation d'option

 

Les options DHCP peuvent être mémorisées dans le paquet DHCP dans trois portions distinctes du paquet. Ce sont le champ paramètres facultatifs, le champ sname, et le champ fichier, comme décrit dans la RFC 2131 [3]. Cela complique la description du mécanisme de partage d'option parce qu'il y a trois champs distincts dans lesquels peuvent être placés les options partagées.

 

Pour encore compliquer les choses, une option qui ne tient pas dans un champ ne peut pas chevaucher la frontière d'un autre champ – l'agent qui code doit à la place casser l'option en deux parties et mémoriser une partie dans chaque mémoire tampon.

 

Pour simplifier cet exposé, nous parlerons d'une mémoire tampon d'agrégation d'option, qui sera l'agrégation des trois mémoires tampon. C'est une agrégation logique – les mémoires tampon DOIVENT apparaître dans les localisations du paquet DHCP décrites dans la RFC 2131 [3].

 

La mémoire tampon d'agrégation d'option est constituée du champ paramètres facultatifs, du champ fichier et du champ sname, dans cet ordre.

 

AVERTISSEMENT    Ce n'est pas l'ordre physique de ces champs dans le paquet DHCP.

 

Les options NE DOIVENT PAS être mémorisées dans la mémoire tampon d'agrégation d'option d'une façon telle qu'aucune d'elles traverse une frontière entre les trois champs dans la mémoire tampon d'agrégation d'option.

 

L'agent qui code a toute liberté pour choisir d'utiliser le champ sname et/ou le champ fichier. Si l'agent qui code ne choisit pas d'utiliser l'un et/ou l'autre de ces deux champs, ils NE DOIVENT PAS dans ce cas être considérés comme faisant partie de la mémoire tampon d'agrégation d'option.

 

6.   Comportement de l'agent qui code

 

Les agents qui codent décident de partager les options sur la base de raisons qui ont été décrites au paragraphe intitulé "Applicabilité" ci-dessus.

 

Les options peuvent être partagées sur toute frontière d'octet. Aucune portion partagée d'une option qui a été partagée ne peut contenir plus de 255 octets. Les portions partagées de l'option DOIVENT être mémorisées dans la mémoire tampon d'agrégation d'option en ordre séquentiel – la première portion partagée DOIT être mémorisée la première dans la mémoire tampon d'agrégation d'option, puis la seconde portion, et ainsi de suite. L'agent qui code ne doit pas essayer de spécifier d'informations sémantiques fondée sur la façon dont l'option est partagée.

 

Noter que parce que la mémoire tampon d'agrégation d'option ne représente pas l'ordre physique du paquet DHCP, si une option était partagée en trois parties et que chaque partie allait dans un des trois champs d'option possibles, la première partie irait dans le champ paramètres facultatifs, la seconde partie irait dans le champ fichier, et la troisième partie irait dans le champ sname. Cela reste cohérent avec le paragraphe 4.1 de la RFC 2131 [3].

 

Chaque portion partagée d'une option DOIT être mémorisée dans la mémoire tampon d'agrégation d'option comme si elle était une option de longueur variable normale, comme décrit dans la RFC 2132 [4]. Les champs longueur de chaque portion partagée de l'option DOIVENT s'ajouter à la longueur totale des données de l'option. Pour une option donnée qui est partagée, le champ code d'option de chaque portion partagée DOIT être le même.

 

7.   Comportement de l'agent qui décode

 

Lorsque un agent qui décode examine la mémoire tampon d'option d'un paquet DHCP entrant et trouve deux ou plusieurs options avec le même code d'option, il DOIT les considérer comme les portions d'une option comme décrit au paragraphe précédent.

 

Dans le cas où un agent qui décode trouve une option partagée, il DOIT traiter le contenu de cette option comme une seule option, et le contenu DOIT être réassemblé dans l'ordre qui a été décrit sous Comportement de l'agent qui code.

 

L'agent qui décode devrait s'assurer que quand la valeur de l'option est utilisée, toute question de verrouillage particulière à l'architecture de la machine sur laquelle fonctionne l'agent qui décode est prise en compte ; il n'est pas exigé que l'agent qui code aligne les options d'une façon particulière.

 

IL n'y a pas de signification sémantique de l'endroit du partage de l'option – l'agent qui code a toute liberté pour effectuer le partage de l'option en tout point, et l'agent qui décode DOIT réassembler les parties de l'option partagée en un seul objet, et il NE DOIT PAS traiter chaque portion partagée de l'option comme un objet distinct.

 

8.   Exemple

 

Considérons une option, Nom de fichier d'amorçage (code d'option 67), avec une valeur de "/diskless/foo". Normalement, cela sera codé comme une seule option, comme suit :

 

 

67

13

/

d

i

s

k

l

e

s

s

/

f

o

o

 

Si un agent qui code a besoin de partager l'option afin de tenir dans la mémoire tampon d'option, il pourrait la coder comme deux options séparées, comme suit, et la mémoriser dans la mémoire tampon d'agrégation d'option selon la séquence suivante :

 

 

67

7

/

d

i

s

k

l

e

 

 

67

6

s

s

/

f

o

o

 

9.   Considérations pour la sécurité

 

Le présent document ne soulève aucun problème de sécurité. Le potentiel d'exposition à des attaques dans le protocole DHCP est discuté à la section 7 de la spécification du protocole DHCP [3] et dans Authentification des messages DHCP [5].

 

Noter que l'option d'authentification peut être elle-même partagée ; dans de tels cas les mises en œuvre doivent faire attention lorsqu'elle mettent le champ authentification à zéro (avant la génération ou la vérification du MAC) car elle peut alors s'étaler sur plusieurs options.

 

10.   Références

10.1   Références normatives

 

[1]   B. Croft et J. Gilmore, "Protocole BOOTSTRAP (BOOTP)", RFC-951, septembre 1985.

 

[2]   S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, RFC 2119, mars 1997.

 

[3]   R. Droms, "Protocole de configuration dynamique d'hôte", RFC 2131, mars 1997.

 

[4]   S. Alexander et R. Droms, "Options DHCP et extensions de fabricant BOOTP", RFC 2132, mars 1997.

 

10.2   Référence pour information

 

[5]   R. Droms et W. Arbaugh, "Authentification des messages DHCP", RFC 3118, juin 2001.

 

11.   Déclaration de droits de 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’IETF au sujet des droits dans les documents en cours de normalisation et se rapportant aux normes figurent dans le BCP 11.

 

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 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, brevet ou applications de brevets, ou autres droits de propriété qui pourraient recouvrir la technologie qui pouurait être nécessaire pour mettre en œuvre la présente norme. Prière d’adresser les informations au directeur exécutif de l’IETF.

 

12.   Adresse des auteurs

 

Stuart Cheshire

Ted Lemon

Apple Computer, Inc.

Nominum, Inc.

1 Infinite Loop

2385 Bay Road

Cupertino

Redwood City, CA 94043

California 95014

USA

USA

mél : mellon@nominum.com

téléphone : +1 408 974 3207

 

mél : rfc@stuartcheshire.org

 

 

13.   Déclaration complète de droits de reproduction

 

Copyright (C) The Internet Society (2002). Tous droits réservés.

 

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.  Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.  

Le présent document et les informations y contenues sont fournies 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 CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

 

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.