|
|
|
|
|
|
Service sans état du protocole de configuration dynamique d'hôte (DHCP) pour IPv6
Statut de ce mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet 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 (2004). Tous droits réservés.
Résumé
Le service sans état du protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6, Stateless Dynamic Host Configuration Protocol service for IPv6) est utilisé par des nœuds pour obtenir les informations de configuration, comme les adresses des serveurs de noms récurrents du DNS, qui n'exigent pas la conservation d'un état dynamique pour les clients individuels. Un nœud qui utilise DHCP sans état doit avoir obtenu ses adresses IPv6 par quelque autre mécanisme, normalement l'autoconfiguration d'adresse sans état. Le présent document explique quelles parties de la RFC 3315 doivent être mises en œuvre dans chacune des différentes sortes d'agents DHCP afin que cet agent puisse prendre en charge DHCP sans état.
Les nœuds qui ont obtenu des adresses IPv6 par d'autres mécanismes, comme l'autoconfiguration d'adresse sans état [RFC2462] ou la configuration manuelle, peuvent utiliser DHCP sans état pour obtenir d'autres informations de configuration comme une liste des serveurs de noms récurrents du DNS ou de serveurs SIP. Un serveur DHCP sans état ne fournit des informations de configuration qu'aux nœuds et n'effectue aucune allocation d'adresse. Un tel serveur est appelé "sans état" parce qu'il n'a pas besoin de conserver d'état dynamique pour les clients individuels.
Alors que la spécification de DHCP [RFC3315] définit plus de 10 messages de protocole et 20 options, seul un sous ensemble de ces messages et options est nécessaire pour le service DHCP sans état. Le présent document explique quels messages et options définis dans la RFC 3315 sont requis pour le service DHCP sans état. L'utilisation prévue pour le document est de guider les mises en œuvre interopérables de clients et serveurs qui utilisent le service DHCP sans état.
Le fonctionnement des agents de relais est le même pour le service DHCP sans état et à état pleins. Le fonctionnement des agents de relais est décrit dans la spécification de DHCP.
La Section 4 de ce document fait la liste des paragraphes du document DHCP que le développeur d'une mise en œuvre devrait lire pour avoir une vue d'ensemble de la spécification DHCP et des exigences de base d'un service DHCP. La Section 5 fait la liste des messages et options spécifiques qui sont précisément exigés pour le service DHCP sans état. La Section 6 décrit comment les serveurs DHCP sans état et à états pleins interagissent pour fournir le service aux clients qui demandent une allocation d'adresse et aux clients qui demandent seulement le service sans état.
Tout au long du présent document, "DHCP" se réfère à DHCP pour IPv6.
Le présent document utilise la terminologie définie dans la [RFC2460], la spécification DHCP [RFC3315], et la spécification des options de configuration de DNS de DHCP [RFC3646].
"DHCP sans état" se réfère à l'utilisation de DHCP pour fournir des informations de configuration aux clients qui n'exigent pas que le serveur conserve l'état dynamique sur les clients DHCP.
3. Généralités
Le présent document suppose qu'un nœud qui utilise la configuration de DHCP sans état n'utilise pas DHCP pour l'allocation d'adresse, et qu'un nœud a déterminé au moins une adresse de liaison locale comme décrit au paragraphe 5.3 de la [RFC2461].
Pour obtenir les paramètres de configuration par DHCP sans état, un nœud utilise le message DHCP Demande d'informations. Les serveurs DHCP répondent au message du nœud avec un message Réponse qui porte les paramètres de configuration pour le nœud. Le message Réponse du serveur peut porter les informations de configuration, comme une liste des serveurs de noms récurrents du DNS [RFC3646] et des serveurs SIP [RFC3319].
Le présent document ne s'applique pas à la fonction des agents DHCP de relais comme décrite dans la RFC 3315. Un élément de réseau peut fournir à la fois le service de serveur DHCP et de relais DHCP. Par exemple, un élément de réseau peut fournir le service DHCP sans état aux hôtes qui demandent le service DHCP sans état, tout en relayant les messages provenant des hôtes qui demandent une allocation d'adresse à travers DHCP à un autre serveur DHCP.
4. Exigences de base pour la mise en œuvre de DHCP
Plusieurs sections de la spécification DHCP fournissent des informations de base ou définissent des sections de la spécification qui sont communes à toutes les mises en œuvre :
1-4 : fait une introduction à DHCP et donne une vue d'ensemble des flux de messages DHCP,
5 : définit les constantes utilisées dans la spécification du protocole,
6, 7 : illustre le format du message DHCP,
8 : décrit la représentation des noms de domaines,
9 : définit un identifiant DHCP univoque (DUID, DHCP unique identifier),
13-16 : décrit la transmission du message DHCP, sa retransmission, et sa validation,
21 : décrit l'authentification pour DHCP.
5. Mise en œuvre de DHCP sans état
Le client indique qu'il demande des informations de configuration par l'envoi d'un message Demande d'informations qui comporte une option Demande d'option spécifiant les options qu'il souhaite recevoir du serveur DHCP. Par exemple, si le client tente d'obtenir une liste des serveurs de noms récurrents du DNS, il identifie l'option Serveur de noms récurrents du DNS dans le message Demande d'informations. Le serveur détermine les paramètres de configuration appropriés pour le client sur la base de sa politique de configuration et répond par un message Réponse contenant les paramètres demandés. Dans cet exemple, le serveur va répondre avec les paramètres de configuration du DNS.
Comme décrit au paragraphe 18.1.5 de la RFC 3315, un nœud peut inclure une option Identifiant de client dans le message Demande d'informations pour s'identifier auprès d'un serveur, parce que l'administrateur du serveur peut vouloir personnaliser la réponse du serveur pour chaque nœud, sur la base de l'identité du nœud.
La RFC 3315 ne définit aucun mécanisme par lequel peut être contrôlé le moment auquel un hôte utilise un message Demande d'informations pour obtenir une mise à jour des paramètres de configuration. Le groupe de travail DHC a entrepris de développement d'un ou de tels mécanismes qui seront publiés comme RFC sur la voie de la normalisation.
La RFC 3315 ne fournit pas non plus de lignes directrices sur le moment où un hôte pourrait utiliser un message Demande d'informations pour obtenir des paramètres de configuration mis à jour lorsque l'hôte s'est déplacé sur une nouvelle liaison. Le groupe de travail DHC est en train de relire un document qui s'y rapporte, "Détection de rattachement réseau (DNA) dans IPv4" [RFC4436], qui décrit comment un hôte qui utilise IPv4 peut déterminer quand utiliser DHCPv4. Le groupe de travail DHC ou un autre formé pour la DNA entreprendra le développement d'un document similaire pour IPv6.
5.1 Messages requis pour le service DHCP sans état
Clients et serveurs mettent en œuvre les messages suivants pour le service DHCP sans état ; dans cette liste les numéros de paragraphe se réfèrent à la spécification DHCP :
Demande d'information : envoyé par un client DHCP à un serveur pour demander les paramètres de configuration (paragraphes 18.1.5 et 18.2.5)
Réponse : envoyé par un serveur DHCP à un client et qui contient les paramètres de configuration (paragraphes 18.2.6 et 18.2.8)
De plus, les serveurs et agents de relais mettent en œuvre les messages suivants pour le service DHCP sans état ; dans cette liste les numéros de paragraphe se réfèrent à la spécification DHCP :
Relais de transmission : envoyé par un agent de relais DHCP pour porter le message du client à un serveur (paragraphe 15.13)
Relais de réponse : envoyé par un serveur DHCP pour porter un message de réponse à l'agent de relais (paragraphe 15.14)
5.2 Options requises pour le service DHCP sans état
Clients et serveurs mettent en œuvre les options suivantes pour le service DHCP sans état ; dans cette liste les numéros de paragraphe se réfèrent à la spécification DHCP :
Demande d'option : spécifie les informations de configuration que le client demande au serveur (paragraphe 22.7).
Code d'état : utilisée pour indiquer l'état d'achèvement ou autres informations d'état (paragraphe 22.13).
Identifiant de serveur : utilisé pour identifier le serveur qui répond à une demande de client (paragraphe 22.3).
Serveurs et agents de relais mettent en œuvre les options suivantes pour le service DHCP sans état ; dans cette liste les numéros de paragraphe se réfèrent à la spécification DHCP :
Message de relais : envoyé par un agent de relais DHCP dans un message Relais de transmission pour porter le message du client à un serveur ou envoyé par un serveur DHCP dans un message Relais de réponse pour porter un message de réponse à l'agent de relais (paragraphe 20).
Identifiant d'interface : envoyé par l'agent de relais DHCP et retourné par le serveur pour identifier l'interface à utiliser lors de la transmission d'un message au client (paragraphe 22.18).
5.3 Options utilisées pour les informations de configuration
Clients et serveurs utilisent les options suivantes pour passer les informations de configuration aux clients ; noter que d'autres options pourront être spécifiées dans de futures normes de l'Internet pour les informations de configuration :
Serveurs de noms récurrents du DNS : spécifie les serveurs de noms récurrents du DNS [RFC1034] que le client utilise pour la résolution des noms ; voir la [RFC3646] "Options de configuration du DNS pour DHCPv6".
Liste de recherche DNS : spécifie les noms de domaines à explorer durant une résolution de noms ; voir la [RFC3646] "Options de configuration du DNS pour DHCPv6".
Serveurs SIP : spécifie les serveurs SIP que le client utilise pour obtenir une liste des noms de domaines des adresses IPv6 qui peuvent être transposées en un ou plusieurs serveurs mandataires SIP sortants [RFC3319]
5.4 Autres options utilisées dans DHCP sans état
Clients et serveurs peuvent mettre en œuvre les options suivantes pour le service DHCP sans état ; dans cette liste les numéros de paragraphe se réfèrent à la spécification DHCP :
Préférence : envoyé par un serveur DHCP pour indiquer le niveau de préférence pour le serveur (paragraphe 22.8)
Temps écoulé : envoyé par un client DHCP pour indiquer le temps écoulé depuis que le client a commencé le processus de configuration DHCP (paragraphe 22.9)
Classe d'utilisateur : envoyé par un client DHCP pour donner des informations supplémentaires au serveur pour choisir les paramètres de configuration pour le client (paragraphe 22.15)
Classe de fabricant : envoyé par un client DHCP pour donner des informations supplémentaires sur le fabricant du client et du matériel au serveur pour choisir les paramètres de configuration pour le client (paragraphe 22.16)
Informations spécifiques du fabricant : utilisé pour passer des informations aux clients dans les options définies par les fabricants (paragraphe 22.17)
Identifiant de client : envoyé par un client DHCP pour s'identifier (paragraphe 22.2). Les clients ne sont pas obligés d'envoyer cette option ; les serveurs renvoient l'option si elle est incluse dans un message provenant d'un client
Authentification : utilisé pour assurer l'authentification des messages DHCP (Section 21)
6. Interaction avec DHCP pour l'allocation d'adresses
Dans certains réseaux, il peut y avoir à la fois des clients qui utilisent l'autoconfiguration d'adresse sans état et DHCP pour la configuration DNS, et des clients qui utilisent DHCP pour la configuration d'adresse à états pleins. Selon le déploiement et la configuration des agents de relais, les serveurs DHCP qui sont destinés seulement à la configuration sans état peuvent recevoir des messages de clients qui effectuent la configuration d'adresse à états pleins.
Un serveur DHCP qui n'est capable que de fournir des informations de configuration sans état dans des échanges de messages Demande/Réponse d'informations éliminent tous les autres messages DHCP qu'ils reçoivent. Précisément, le serveur élimine tout message autre que les Demandes d'information ou Relais de transmission qu'il reçoit, et le serveur ne participe à aucun échange de message de configuration d'adresse. Si il y a d'autres serveurs DHCP qui sont configurés à fournir des allocations d'adresse à états pleins, un de ces serveurs va fournir l'allocation d'adresse.
7. Considérations sur la sécurité
Le service DHCP sans état est un sous ensemble approprié du service DHCP décrit dans la spécification DHCP, [RFC3315]. Donc, le service DHCP sans état n'introduit aucune considération de sécurité au delà de celles exposées aux sections 21, 22.11, et 23 de la spécification DHCP [RFC3315].
Les informations de configuration fournies à un nœud au moyen du service DHCP sans état peuvent être utilisées pour monter des attaques d'usurpation d'identité, par interposition, de déni de service, et autres. Ces attaques sont décrites plus en détails dans les spécifications de chacune des options qui portent les informations de configuration. DHCP authentifié, comme décrit aux sections 21 et 22.11 de la spécification DHCP [RFC3315], peut être utilisé pour éviter les attaques montées à travers le service DHCP sans état.
Jim Bound, Ted Lemon, et Bernie Volz ont relu le présent document et ont contribué à des suggestions rédactionnelles. Merci à Peter Barany, Tim Chown, Christian Huitema, Tatuya Jinmei, Pekka Savola, et Juha Wiljakka de leur relecture et leurs commentaires.
[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 et RFC6644, RFC7227)
[RFC2460] S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", décembre 1998. (MàJ par 5095, 6564 ; D.S)
9.2 Références pour information
[RFC1034] P. Mockapetris, "Noms de domaines - Concepts et facilités", STD 13, novembre 1987.
[RFC2461] T. Narten, E. Nordmark, W. Simpson, "Découverte de voisins pour IP version 6 (IPv6)", décembre 1998. (Obsolète, voir RFC4861) (D.S.)
[RFC2462] S. Thomson, T. Narten, "Autoconfiguration d'adresse IPv6 sans état", décembre 1998. (Obsolète, voir RFC4862) (D.S.)
[RFC3319] H. Schulzrinne, B. Volz, "Options du protocole de configuration dynamique d'hôte (DHCPv6) pour serveurs de protocole d'initialisation de session (SIP)", juillet 2003. (P.S.)
[RFC3646] R. Droms, éd., "Options de configuration du DNS pour le protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)", décembre 2003. (P.S.)
[RFC4436] B. Aboba et autres, "Détection des rattachements au réseau dans IPv4 (DNAv4)", mars 2006. (P.S.)
Ralph Droms
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
téléphone : +1 978 497 4733
mél : rdroms@cisco.com
11. Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2004).
Le présent document est soumis aux droits, licenses et restrictions contenues dans le BCP 78 et sauf comme mentionné ci-dessous, 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 incluses 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 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 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’Internet Society.