Groupe de travail Réseau	G. Waters, Nortel Networks	
Request for Comments : 3011	novembre 2000	
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle	

Option Sélection de sous-réseau IPv4 pour DHCP

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 (2000). Tous droits réservés.

Résumé
Le présent mémoire définit une nouvelle option du protocole de configuration dynamique d’hôte (DHCP, Dynamic Host Configuration Protocol) pour choisir le sous-réseau sur lequel allouer une adresse. Cette option va supplanter les méthodes normales d’un serveur DHCP pour choisir le sous-réseau sur lequel allouer une adresse pour un client.

Table des matières
1. Introduction	1
1.1 Exemple des motifs de l’option	2
2. Définition de l’option Sélection de sous-réseau	2
3. Propriété intellectuelle	3
4. Considérations relatives à l’IANA 	3
5. Remerciements	3
6. Considérations pour la sécurité	3
7. Références	3
8. Adresse de l’éditeur	4
9. Déclaration complète de droits de reproduction	4

1.	Introduction

Le protocole de configuration dynamique d’hôte (DHCP) [RFC2131] donne un cadre pour passer les informations de configuration aux hôtes sur un réseau TCP/IP. La [RFC2132] spécifie les informations de configuration d’option DHCP qui peuvent être portées dans les paquets DHCP de/vers le serveur DHCP et le client DHCP. Le présent document spécifie une nouvelle option DHCP.

Pour choisir le sous-réseau sur lequel allouer une adresse, le serveur DHCP détermine le sous-réseau à partir duquel la demande a été générée, et choisit ensuite une adresse sur le sous-réseau d’origine ou sur un sous-réseau qui est sur le même segment de réseau que le sous-réseau d’origine. Le sous-réseau à partir duquel la demande a été générée peut être déterminé par :
o	l’adresse de sous-réseau du champ giaddr dans l’en-tête du paquet DHCP, ou si le champ giaddr est à zéro,
o	en utilisant l’adresse de sous-réseau de l’interface locale sur laquelle le serveur DHCP a reçu le paquet.

Le présent mémoire définit une nouvelle option DHCP, l’option Sélection de sous-réseau, qui permet au client DHCP de spécifier le sous-réseau sur lequel allouer une adresse. Cette option prend le pas sur les méthodes que le serveur DHCP utilise pour déterminer le sous-réseau sur lequel choisir une adresse.

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

1.1	Exemple des motifs de l’option

Un exemple d’utilisation de cette option est dans un appareil (par exemple, un appareil RAS) qui alloue des adresses au nom de ses clients. Dans ce cas, l’appareil va allouer des adresses par l’intermédiaire de DHCP et va ensuite gérer ces adresses parmi ses clients.

Dans ce scénario, l’appareil est connecté à un réseau "interne" privé sur lequel le serveur DHCP serait situé. L’appareil est aussi connecté à un ou plusieurs réseaux "externes" fournisseurs de services (c’est-à-dire, les réseaux auxquels les clients de l’appareil sont connectés). De plus, le réseau interne n’est pas connecté par IP aux réseaux externes, bien qu’à l’intérieur de l’appareil, il y ait la connexité entre le réseau interne et les réseaux externes (par exemple, à travers l’arrière plan).

On se rappelle que l’appareil alloue des adresses pour ses clients sur les réseaux externes et qu’il n’y a pas de connexité IP entre le réseau interne et les réseaux externes. Les demandes DHCP ne peuvent pas être générées à partir des réseaux externes car les paquets ne peuvent pas être acheminés entre les réseaux externes et le réseau interne. Donc, les demandes DHCP doivent provenir du réseau interne. Le problème avec la génération des demandes DHCP à partir du réseau interne est que le serveur DHCP va allouer les adresses sur le sous-réseau du réseau interne, alors que ce qui est demandé est des adresses sur les sous-réseaux externes. L’option Sélection de sous-réseau apporte une solution à ce problème.

L’appareil enverrait sa demande DHCP sur le sous-réseau interne, mais inclurait l’option Sélection de sous-réseau contenant l’adresse du sous-réseau externe sur lequel il demande l’adresse. L’option Sélection de sous-réseau indique au serveur DHCP d’allouer l’adresse sur le sous-réseau demandé par opposition au fonctionnement normal d’allocation d’adresse sur le sous-réseau à partir duquel la demande DHCP a été générée.

2.	Définition de l’option Sélection de sous-réseau

L’option Sélection de sous-réseau est une option DHCP. Elle contient une seule adresse IPv4 qui est l’adresse d’un sous-réseau. La valeur pour l’adresse de sous-réseau est déterminée en prenant une adresse IPv4 quelconque sur le sous-réseau et en ajoutant cette adresse au gabarit du sous-réseau (c’est-à-dire que les bits du réseau et du sous-réseau sont laissés à part et que les bits restants (de l’adresse) sont mis à zéro). Lorsque le serveur DHCP est configuré pour répondre à cette option, à allouer une adresse, et que cette option est présente, alors le serveur DHCP DOIT allouer l’adresse :
o	soit sur le sous-réseau spécifié dans l’option Sélection de sous-réseau, 
o	soit sur un sous-réseau sur le même segment de réseau que le sous-réseau spécifié dans l’option Sélection de sous-réseau.

Le format de l’option est :

        Code   Long      Adresse IPv4 
       +-----+-----+-----+-----+-----+-----+
       | 118 |  4  | A1  | A2  | A3  | A4  |
       +-----+-----+-----+-----+-----+-----+

Les serveurs configurés pour prendre en charge cette option DOIVENT retourner une copie identique de l’option à tout client qui l’envoie, sans considérer si le client demande ou non l’option dans une liste de demande de paramètre. Les clients qui utilisent cette option DOIVENT éliminer les paquets DHCPOFFER ou DHCPACK qui ne contiennent pas cette option.

Cette option n’exige pas de changement des opérations ou caractéristiques du serveur DHCP autre que de choisir le sous-réseau sur lequel allouer une adresse. Par exemple, le traitement de DHCPDISCOVER pour un sous-réseau inconnu devrait continuer inchangé.

Lorsque cette option est présente et que le serveur est configuré pour prendre en charge cette option, le serveur NE DOIT PAS offrir une adresse qui n’est pas sur le sous-réseau ou segment de réseau demandé. Les serveurs qui ne comprennent pas cette option alloueront une adresse en utilisant leurs algorithmes normaux et ne retourneront pas cette option dans le DHCPOFFER ou DHCPACK. Dans ce cas, le client éliminera le DHCPOFFER ou DHCPACK. Les serveurs qui comprennent cette option mais sont administrativement configurés pour ignorer l’option DOIVENT ignorer l’option, utiliser leurs algorithmes normaux pour allouer une adresse, et NE DOIVENT PAS retourner cette option dans le DHCPOFFER ou DHCPACK. Dans ce cas, le client éliminera le DHCPOFFER ou DHCPACK.

Durant un renouvellement d’adresse, le serveur DHCP peut envoyer un DHCPACK directement à l’adresse allouée, mais les paquets provenant du serveur DHCP peuvent n’être pas acheminables à l’adresse. Donc, dans tous les paquets que le client DHCP envoie qui contiennent l’option Sélection de sous-réseau, le champ giaddr dans l’en-tête BOOTP DOIT être réglé à une adresse IPv4 sur laquelle le client DHCP va accepter les paquets DHCP (par exemple, l’adresse sur le sous-réseau connectée au réseau interne).

L’adresse IPv4 à laquelle un serveur DHCP envoie une réponse DOIT être la même que celle qu’il choisirait si l’option n’était pas présente.

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

4.	Considérations relatives à l’IANA 

L’IANA a alloué une valeur de 118 au code d’option DHCP décrite dans le présent document.

5.	Remerciements

Ce document est le résultat du travail entrepris par le groupe de travail DHCP. Merci à Ted Lemon, Tim Aston et Ralph Droms pour leurs commentaires utiles sur ce travail.

W. Mark Townsley et Pratik Gupta ont publié en juillet 1997 un projet Internet original sur l’option Sélection de sous-réseau. Le présent document ne se fonde pas sur ce travail original mais poursuit le même but.

6.	Considérations pour la sécurité

DHCP ne fournit actuellement pas de mécanisme d’authentification ni de sécurité. Les expositions potentielles aux attaques sont discutées à la section 7 de la spécification du protocole [RFC2131].
L’option Sélection de sous-réseau permet au client DHCP de spécifier le sous-réseau sur lequel allouer une adresse. Cela permettrait au client d’effectuer une attaque plus complète d’épuisement de réservoir d’adresses car le client n’aurait plus de restriction à une attaque du réservoir d’adresses juste sur son sous-réseau local.
Les serveurs qui mettent en œuvre l’option Sélection de sous-réseau DOIVENT par défaut désactiver l’utilisation de ce dispositif ; il doit être spécifiquement activé par l’intermédiaire de la configuration. De plus, un serveur DEVRAIT fournir la capacité d’activer de façon sélective l’utilisation du dispositif dans des conditions précises, par exemple, en n’activant l’utilisation de l’option que de la part d’identifiants de clients explicitement configurés, en n’activant son utilisation que par des clients sur un sous-réseau particulier, ou en restreignant les sous-réseaux (comme indiqué dans l’option Sélection de sous-réseau) à partir desquels les adresses peuvent être demandées.

7.	Références

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

[RFC2131]	R. Droms, "Protocole de configuration dynamique d'hôte", mars 1997. (Mise à jour par les RFC 3396  et 4361 )

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

8.	Adresse de l’éditeur

Glenn Waters
Nortel Networks
310-875 Carling Avenue,
Ottawa, Ontario K1S 5P1
Canada
téléphone :  +1 613-765-0249
mél :  gww@nortelnetworks.com 

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

Copyright (C) The Internet Society (2000). 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.