Groupe de travail Réseau	M. Stapp, Cisco Systems, Inc.	
Request for Comments : 4243	R. Johnson, Cisco Systems, Inc.	
Catégorie : Sur la voie de la normalisation	T. Palaniappan, Cisco Systems, Inc.	
Traduction Claude Brière de L'Isle	décembre 2005	

Sous option Informations spécifiques de fabricant pour l'option d'agent de relais du protocole de configuration dynamique d'hôte (DHCP)

Statut de ce mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la 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 (2005).

Résumé
Le présent mémoire définit une nouvelle sous option "Informations spécifiques du fabricant" pour l'option d'informations d'agent de relais du protocole de configuration dynamique d'hôte (DHCP, Dynamic Host Configuration Protocol). La sous option permet à un agent de relais DHCP d'inclure des informations spécifiques du fabricant dans les messages DHCP qu'il transmet, comme configurées par son administrateur.
Table des matières
1. Introduction	1
2. Terminologie des exigences	2
3. Sous option spécifique de fabricant	2
4. Comportement de l'agent de relais	2
5. Comportement du serveur DHCP	3
6. Considérations sur la sécurité	3
7. Considérations relatives à l'IANA	3
8. Remerciements	3
9. Références	3
9.1 Références normatives	3
9.2 Références pour information	4
Adresse des auteurs	4
Déclaration complète de droits de reproduction	4

 	1.	Introduction

DHCP [RFC2131] fournit des informations d'adresses IP et de configuration pour les clients IPv4. Il inclut une capacité d'agent de relais dans laquelle des processus au sein de l'infrastructure réseau reçoiven des messages diffusés provenant des clients et les transmettent aux serveurs DHCP comme messages en envoi individuel. Dans des environnements de réseau comme les données sur le câble DOCSIS et xDSL, par exemple, il s'est révélé utile pour l'agent de relais d'ajouter des informations au message DHCP avant de le transmettre, en utilisant l'option d'informations d'agent de relais de la [RFC3046].

Les serveurs qui reconnaissent l'option d'agent de relais y font un écho en retour dans leurs répétitions, et certaines des informations que les relais ajoutent peuvent être utilisées pour aider efficacement un appareil de bordure à retourner des réponses aux clients. Les informations que les relais fournissent peuvent aussi être utilisées dans la prise de décision du serveur sur les adresses et les paramètres de configuration que le client devrait recevoir.

Dans de nombreux environnements, il est désirable d'associer des informations spécifiques du fabricant ou du fournisseur aux messages DHCP des clients. Ceci est souvent fait en utilisant l'option d'informations de l'agent de relais. La RFC 3046 définit les options Remote-ID (identifiant distant) et Circuit-ID (identifiant de circuit) qui sont utilisées pour porter de telles informations. Les valeurs de ces sous options, sont cependant généralement fondées sur une ressource du réseau, comme l'adresse IP d'un appareil d'accès au réseau, un identifiant de circuit virtuel ATM, ou un identifiant de modem câble DOCSIS. Par suite, les valeurs portées dans ces sous options dépendent de la configuration physique du réseau. La sous option Informations spécifiques de fabricant permet aux administrateurs d'associer d'autres données utiles aux messages DHCP relayés.

 	2.	Terminologie des exigences

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	3.	Sous option spécifique de fabricant

Le présent mémoire définit une nouvelle sous option à l'option d'agent de relais DHCP qui porte les données définies par le fabricant. La sous option prend une forme similaire à celle de l'option Vendor-Identifying, Vendor-Specific [RFC3925].

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |    Longueur   |        Entreprise numéro1     .
+---------------+---------------+---------------+---------------+
.                               | Long. données1|               |
+---------------+---------------+---------------+               +
\                    Données de sous option 1                   \
+---------------+---------------+---------------+---------------+
|                      Entreprise numéro2                       |
+---------------+---------------+---------------+---------------+
| Long. données2|         Données de sous option 2              |
+---------------+---------------+---------------+---------------+
\                                                               \
.                                                               .
.                                                               .
+---------------+---------------+---------------+---------------+

Le code de la sous option est 9.

Le champ Longueur d'un octet est la longueur des données portées dans la sous option, en octets. La longueur inclut la longueur du premier numéro d'entreprise ; la longueur minimum est 4 octets.

"Numéro d'entrepriseN" est un numéro d'entreprise enregistré par l'IANA [IANA]. C'est une valeur d'entier de quatre octets dans l'ordre des octets du réseau.

Long. donnéesN est la longueur des données associées au numéro d'entreprise.

Les données de sous option sont une séquence opaque d'octets.

La sous option spécifique de fabricant inclut au moins un numéro d'entreprise et porte des données opaques définies par l'organisation identifiée par le numéro d'entreprise. Un relais peut inclure des données associées à plus d'un numéro d'entreprise du fabricant au sein d'une seule instance de la sous option.

Bien sûr, les données spécifiques de fabricant sont spécifiques du fabricant. La présente spécification n'établit aucune exigence sur les données de la sous option. Les fabricants qui utilisent cette sous option sont encouragés à documenter leur usage afin de rendre l'interopérabilité possible.

 	4.	Comportement de l'agent de relais

Les agents de relais DHCP PEUVENT être configurés à inclure les sous options spécifiques de fabricant si ils incluent l'option d'informations d'agent de relais dans les messages DHCP relayés. Les types de sous options de données sont alloués et configurés par des mécanismes qui sortent du domaine d'application du présent mémoire.

Les mises en œuvre de relais sont encouragées à offrir à leurs administrateurs un moyen de configurer les données qui peuvent être incluses dans cette sous option à documenter ce dont elles sont capables.

 	5.	Comportement du serveur DHCP

Cette sous option fournit des informations supplémentaires au serveur DHCP. Le serveur DHCP, si il est configuré à prendre en charge cette sous option, peut utiliser ces informations, en plus des autres données d'option d'agent de relais et des autres options incluses dans les messages de client DHCP, afin d'allouer une adresse IP et/ou d'autres paramètres de configuration au client. Il n'y a pas de traitement particulier supplémentaire pour cette sous option.

 	6.	Considérations sur la sécurité

L'authentification de message dans DHCP pour l'usage en intradomaine, où l'échange hors bande d'un secret partagé est faisable, est définie dans la [RFC3118]. Les expositions potentielles à des attaques sont discutées à la Section 7 de la spécification du protocole DHCP dans la [RFC2131].

L'option d'agent de relais DHCP dépend d'une relation de confiance entre l'agent de relais DHCP et le serveur, comme décrit à la section 5 de la [RFC3046]. Des données frauduleuses d'option d'agent de relais pourraient conduire à un vol potentiel de service ou à l'épuisement de ressources limitées (comme des adresses IP) par des clients non autorisés. Un hôte qui altérerait les données d'agent de relais associées aux messages DHCP d'un autre hôte pourrait dénier le service à cet hôte, ou interférer avec son fonctionnement en conduisant le serveur DHCP à lui allouer des paramètres de configuration inappropriés.

Bien que l'introduction d'options frauduleuses d'agent de relais puisse être empêchée par un périmètre de défense qui bloque ces options sauf si l'agent de relais est de confiance, une défense plus en profondeur utilisant l'authentification pour les options d'agent de relais via la sous option Authentification [RFC4030] DEVRAIT aussi être déployée.

Il y a plusieurs données dans un message DHCP qui portent des informations pouvant identifier un hôte individuel sur le réseau. Cela inclut les champs chaddr, option d'identifiant de client, et les options hostname et client-fqdn. Selon le type de données incluses, la sous option Vendor-Specific peut aussi porter des informations qui identifient un hôte spécifique ou un utilisateur spécifique sur le réseau. En pratique, ces informations ne sont pas exposées en dehors du réseau internet du fournisseur de service, où les messages DHCP sont généralement confinés. Les administrateurs qui configurent les données qui seront utilisées dans les sous options DHCP Vendor-Specific devraient faire attention à utiliser des données appropriées pour les types de réseaux qu'ils administrent. Si les messages DHCP voyagent en dehors du propre réseau du fournisseur de service, ou si les valeurs de sous option peuvent devenir visibles aux autres utilisateurs, cela peut soulever des problèmes de confidentialité pour le fournisseur d'accès ou de service.

 	7.	Considérations relatives à l'IANA

L'IANA a alloué le numéro de sous option 9 à la sous option "Informations spécifiques de fabricant" dans l'espace de numéros de sous option de l'option d'informations d'agent de relais DHCP [RFC3046].

 	8.	Remerciements

Les auteurs remercient Andy Sudduth, Josh Littlefield, et Kim Kinnear de leur relecture et commentaires.

 	9.	Références
 	9.1	Références normatives

[IANA]	IANA, "Private Enterprise Numbers ( http://www.iana.org/assignments/enterprise-numbers.html )".

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

[RFC2131]	R. Droms, "Protocole de configuration dynamique d'hôte", mars 1997. (DS) (Mà J par RFC3396, RFC4361, RFC5494, et RFC6849)

[RFC3046]	M. Patrick, "Option DHCP Information d'agent de relais", janvier 2001. (MàJ par RFC6607)

 	9.2	Références pour information

[RFC3118]	R. Droms et W. Arbaugh, "Authentification des messages DHCP", juin 2001. (P.S.) 

[RFC3925]	J. Littlefield, "Option de fabricant Identification du fabricant pour le protocole de configuration dynamique d'hôte, version  4 (DHCPv4)", octobre 2004. (P.S.)

[RFC4030]	M. Stapp, T. Lemon, "Sous-option d'authentification de l'option d'agent de relais pour le protocole de configuration dynamique d'hôte (DHCP)", mars 2005. (P.S.)

 	Adresse des auteurs

Mark Stapp	Richard Johnson	Theyn Palaniappan	
Cisco Systems, Inc.	Cisco Systems, Inc.	Cisco Systems, Inc.	
1414 Massachusetts Ave.	170 W. Tasman Dr.	170 W. Tasman Dr.	
Boxborough, MA  01719	San Jose, CA  95134	San Jose, CA  95134	
USA	USA	USA	
téléphone : 978.936.0000	téléphone : 408.526.4000	téléphone : 408.526.4000	
mél : mjs@cisco.com 	mél : raj@cisco.com 	mél : athenmoz@cisco.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

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 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.

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 pourraient ê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 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 la Internet Society.