Option Route statique sans classe pour le protocole de configuration dynamique d'hôte (DHCP) version 4

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 définit une nouvelle option du protocole de configuration dynamique d'hôte (DHCP, Dynamic Host Configuration Protocol) qui est passée du serveur DHCP au client DHCP pour configurer une liste de chemins statiques chez le client. Les destinations réseau de ces chemins sont sans classe – chaque entrée du tableau d'acheminement inclut un gabarit de sous-réseau.

Introduction

Cette option rend obsolète l'option Route statique (option 33) définie dans la RFC 2132 [4].

Le protocole IP [1] utilise des routeurs pour transmettre les paquets des hôtes connectés à un sous-réseau IP aux hôtes connectés à un sous-réseau IP différent. Lorsque un hôte IP (l'hôte source) souhaite transmettre un paquet à un autre hôte IP (la destination), il consulte son tableau d'acheminements pour déterminer l'adresse IP du routeur qui devrait être utilisé pour transmettre le paquet à l'hôte de destination.

Il y a diverses façons d'entretenir le tableau d'acheminemetn sur un hôte IP : on peut utiliser un protocole d'informations d'acheminement tel que RIP [8], la découverte de routeur ICMP [6,9] ou utiliser l'option de routeur DHCP, définie dans la RFC 2132 [4].

Dans un réseau qui fournit déjà le service DHCP, l'utilisation de DHCP pour mettre à jour le tableau d'acheminement sur un client DHCP a plusieurs avantages. C'est efficace, car cela utilise des messages qui seraient envoyés de toutes façons. C'est pratique, car la configuration de serveur DHCP est déjà en service, donc l'entretien des informations d'acheminement, au moins sur un réseau relativement stable, ne requiert que peu de travail supplémentaire. Si le service DHCP est déjà activé, aucune infrastructure supplémentaire n'est à mettre en place.

Le protocole DHCP tel qu'il est défini dans la RFC 2131 [3] et les options définies dans la RFC 2132 [4] ne font que fournir un mécanisme pour installer un chemin par défaut ou installer un tableau des chemins classés. Les chemins classés sont ceux dont le gabarit de sous-réseau est implicite dans le numéro de sous-réseau – voir au paragraphe 3.2 du STD 5, RFC 791 [1] les précisions sur l'acheminement de classe.

L'acheminement de classe n'est plus d'utilisation courante de sorte que l'option DHCP d'acheminement statique n'est plus utile. Actuellement, l'acheminement sans classe [7, 10] est la forme d'acheminement la plus communément répandue sur l'Internet. Dans l'achemineemtn sans classe, les adresses IP comportent un numéro de réseau (la combinaison du numéro de réseau et du numéro de sous-réseau décrite dans la RFC 950 [7]) et un numéro d'hôte.

Dans l'IP à classes, le numéro de réseau et le numéro d'hôte sont déduits de l'adresse IP en utilisant un gabarit binaire dont la valeur est déterminée par les premiers bits de l'adresse IP. Dans l'IP sans classe, le numéro de réseau et le numéro d'hôte sont déduits de l'adresse IP en utilisant des quantités distinctes, le gabarit de sous-réseau. Afin de déterminer le réseau auquel un chemin donné s'applique, un hôte IP doit savoir à la fois le numéro de réseau ET le gabarit de sous-réseau pour ce réseau.

L'option Routes statiques (option 33) ne fournit pas de gabarit de sous-réseau pour chaque chemin – on suppose que le gabarit de sous-réseau est implicite dans chaque numéro de réseau spécifié dans chaque entrée de chemin. L'option Routes statiques sans classe fournit un gabarit de sous-réseau pour chaque entrée, de sorte que le gabarit de sous réseau peut être autre que ce qui aurait été déterminé en utilisant l'algorithme spécifié dans le STD 5, RFC 791 [1] et RFC 950 [7].

Définitions

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

Le présent document utilise aussi les termes suivants :

"Client DHCP"

Le client DHCP ou "client" est un hôte Internet qui utilise DHCP pour obtenir des paramètres de configuration tels qu'une adresse réseau.

"Serveur DHCP"

Un serveur DHCP ou "serveur" est un hôte Internet qui retourne les paramètres de configuration aux clients DHCP.

"liaison"

Tout ensemble de points de rattachement au réseau qui va recevoir une diffusion de couche liaison envoyée sur n'importe lequel des points de rattachement. Ce terme est utilisé dans DHCP parce que dans certains cas, plus d'un sous-réseau IP peut être configuré sur une liaison. DHCP utilise une diffusion de réseau local (tout à un), qui n'est pas spécifique du sous-réseau, et atteindra donc tous les nœuds connectés à la liaison, sans considération du ou des sous-réseaux IP sur lesquels ils sont configurés. Une "liaison" est parfois désignée comme un domaine de diffusion ou un segment de réseau physique.

Format d'option de chemin sans classe

Le code de cette option est 121, et sa longueur minimum est de 5 octets. Cette option peut contenir un ou plusieurs chemins statiques, chacun d'eux consistant en un descripteur de destination et l'adresse IP du routeur qui devrait être utilisé pour atteindre cette destination.

 Code  Lon Destination 1   Routeur 1

+-----+---+----+-----+----+----+----+----+----+

| 121 | n | d1 | ... | dN | r1 | r2 | r3 | r4 |

+-----+---+----+-----+----+----+----+----+----+

 Destination 2        Routeur 2

+----+-----+----+----+----+----+----+

| d1 | ... | dN | r1 | r2 | r3 | r4 |

+----+-----+----+----+----+----+----+

Dans l'exemple ci-dessus, deux chemins statiques sont spécifiés.

Les descripteurs de destination décrivent le numéro de sous-réseau IP et le gabarit de sous-réseau pour une destination particulière en utilisant un codage compact. Ce codage consiste en un octet qui décrit la largeur du gabarit de sous-réseau, suivi par tous les octets significatifs du numéro de sous-réseau.

La largeur du gabarit de sous-réseau décrit le nombre de bits à un dans le gabarit, ainsi par exemple un sous-réseau avec un numéro de sous-réseau de 10.0.127.0 et un gabarit de réseau de 255.255.255.0 aurait un gabarit de sous-réseau de 24.

La portion significative du numéro de sous-réseau est simplement tous les octets du numéro de sous-réseau où l'octet correspondant dans le gabarit de sous-réseau est différent de zéro. Le nombre d'octets significatifs est la largeur du gabarit de sous-réseau divisé par huit, arrondi à la valeur supérieure, comme indiqué par le tableau suivant :

Le tableau suivant contient des exemples de la façon dont peuvent être codées diverses combinaisons de sous-réseau/gabarit :

Chemins de sous-réseau local

Dans certains cas, plus d'un sous-réseau IP peut être configuré sur une liaison. Dans de tels cas, un hôte dont l'adresse IP est dans un sous-réseau IP sur la liaison pourrait communiquer directement avec un hôte dont l'adresse IP est dans un sous-réseau IP différent sur la même liaison. Dans les cas où un client se voit allouer une adresse IP sur un sous-réseau IP qui est sur une telle liaison, pour chaque sous-réseau IP de la liaison autre que le sous-réseau IP sur lequel le client a été alloué, le serveur DHCP PEUT être configuré pour spécifier une adresse IP de routeur de 0.0.0.0.

Par exemple, considérons le cas où il y a trois sous-réseaux IP configurés sur une liaison : 10.0.0/24, 192.168.0/24, 10.0.21/24. Si il est alloué au client une adresse IP de 10.0.21.17, le serveur peut alors inclure un chemin avec une destination de 10.0.0/24 et une adresse de routeur de 0.0.0.0, et aussi un chemin avec une destination de 192.168.0/24 et une adresse de routeur de 0.0.0.0.

Un client DHCP dont la pile TCP/IP sous-jacente ne fournit pas cette capacité DOIT ignorer les chemins dans les chemins statiques sans classe dont l'adresse IP de routeur est 0.0.0.0. Prière de noter que le comportement décrit ici ne s'applique qu'à l'option Route statique sans classe, et pas à l'option Routes statiques ni à l'option Routeur.

Comportement du client DHCP

Les clients DHCP qui ne prennent pas en charge cette option DOIVENT l'ignorer si elle est reçue d'un serveur DHCP. Les clients DHCP qui prennent en charge cette option DOIVENT installer les chemins spécifiés dans l'option, excepté comme spécifié dans la section Routes de sous-réseau local. Les clients DHCP qui prennent en charge cette option NE DOIVENT PAS installer les chemins spécifiés dans l'option Routes statiques (code d'option 33) si les deux options Routes statiques et Routes statiques sans classe sont fournies.

Les clients DHCP qui prennent en charge cette option et qui envoient une option Liste de demande de paramètres DHCP DOIVENT demander à la fois cette option et l'option Routeur [4] dans la liste de demande de paramètres DHCP.

Les clients DHCP qui prennent en charge cette option et envoient une demande de liste de paramètres PEUVENT aussi demander l'option Routes statiques, pour la compatibilité avec les serveurs anciens qui ne prennent pas en charge Routes statiques sans classe. Le code de l'option Routes statiques sans classe DOIT apparaître dans la demande de liste de paramètres avant le code d'option Routeur et le code d'option Routes statique, s'ils sont présents.

Si le serveur DHCP retourne les deux options Routes statique sans classe et Routeur, le client DHCP DOIT ignorer l'option Routeur.

De même, si le serveur DHCP retourne les deux options Routes statiques sans classe et Routes statiques, le client DHCP DOIT ignorer l'option Routes statiques.

Après avoir déduit un numéro de sous-réseau et un gabarit de sous-réseau de chaque description de destination, le client DHCP DOIT mettre à zéro tous les bits du numéro de sous-réseau où le bit correspondant du gabarit est à zéro. En d'autres termes, le numéro de sous-réseau installé dans les tableaux d'acheminement est le ET logique du numéro de sous-réseau et du gabarit de sous-réseau donnés dans l'option Routes statiques sans classe. Par exemple, si le serveur envoie une route avec une destination de 129.210.177.132 (81D4B184 en hexadécimal) et un gabarit de sous-réseau de 255.255.255.128 (FFFFFF80 en hexadécimal), le client va installer une route avec une destination de 129.210.177.128 (81D4B180 en hexadécimal).

Exigences pour éviter les contraintes de taille

Comme un tableau d'acheminement complet peut être assez grand, la taille maximum standard de 576 octets pour un message DHCP peut être trop courte pour contenir des options légitimes de Route statique sans classe. À cause de cela, les clients qui mettent en œuvre l'option Route statique sans classe DEVRAIENT envoyer l'option Taille maximum de message DHCP [4] si la pile TCP/IP du client DHCP est capable de recevoir de plus grands datagrammes IP. Dans ce cas, le client DEVRAIT régler la valeur de cette option au moins à la MTU de l'interface que configure le client. Le client PEUT régler la valeur de cette option plus haut, jusqu'à la taille du plus grand paquet UDP qu'il est prêt à accepter. (Noter que la valeur spécifiée dans l'option Taille maximum de message DHCP est la taille de paquet totale maximum, y compris les en-têtes IP et UDP.)

Les clients DHCP qui demandent cette option, et les serveurs DHCP qui envoient cette option, DOIVENT mettre en œuvre l'enchaînement d'options DHCP [5]. Dans la terminologie de la RFC 3396 [5], l'option Route statique sans classe est une option qui exige l'enchaînement.

Responsabilités de l'administrateur du serveur DHCP

Il est possible que de nombreux clients ne mettent pas en œuvre l'option Routes statiques sans classe. Les administrateurs de serveur DHCP devraient donc configurer leurs serveurs DHCP de telle sorte qu'ils envoient les deux options Routeur et Route statique sans classe, et ils devraient spécifier le ou les routeurs par défaut avec à la fois l'option Routeur et l'option Route statique sans classe.

Lorsque un client DHCP demande l'option Route statique sans classe et demande aussi l'une et/ou l'autre des options Routeur et Route statique, et que le serveur DHCP envoie l'option Route statique sans classe à ce client, le serveur NE DEVRAIT PAS inclure les options Routeur ou Route statique.

Considérations pour la sécurité

Les expositions potentielles aux attaques dans le protocole DHCP sont discutées à la section 7 de la spécification du protocole DHCP [3] et dans "Authentification des messages DHCP" [11].

L'option Routes statiques sans classe peut être utilisée pour détourner du trafic réseau en fournissant des adresses réseau IP incorrectes pour les routeurs. Cela peut être aussi bien utilisé pour une attaque de déni de service, où l'adresse IP du routeur donnée est tout simplement invalide, que pour monter une attaque par interposition en fournissant l'adresse IP d' un espion potentiel. Ce n'est pas un problème nouveau – les options existantes Routeur et Routes statiques définies dans la RFC 2132 [4] exhibent la même faiblesse.

Considérations relatives à l'IANA

Cette option DHCP a reçu le code d'option 121 dans la liste des codes d'option DHCP tenue par l'IANA.

Références normatives

[1]   J. Postel, "Protocole Internet", STD 5, RFC 791, septembre 1981.

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

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

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

[5]   T. Lemon et S. Cheshire, "Codage d'options longues dans le protocole de configuration dynamique d'hôte (DHCPv4)", RFC 3396, novembre 2002.

Références informatives

[6]   J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", RFC 792, STD 5, septembre 1981.

[7]   J. Mogul et J. Postel, "Procédure standard de sous-réseautage Internet", RFC 950, (STD 5) août 1985.

[8]   C. Hedrick, "Protocole d'informations d'acheminement", RFC 1058, juin 1988. (Historique)

[9]   S. Deering, éditeur, "Messages ICMP de découverte de routeur", RFC 1256, septembre 1991.

[10]   T. Pummill, B. Manning, "Tableau de sous-réseau de longueur variable pour IPv4", RFC 1878, décembre 1995. (Remplace RFC1860) (Historique)

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

Déclaration 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.

Adresse des auteurs

Déclaration complète de droits de reproduction

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

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.