RFC4311 Partage de charge d'hôte à routeur dans IPv6 Hinden & Thaler
Groupe de travail Réseau R. Hinden, Nokia
Request for Comments : 4311 D. Thaler, Microsoft
RFC mise à jour : 2461 novembre 2005
Catégorie : Sur la voie de la normalisation Traduction Claude Bière de L'Isle
Partage de charge d'hôte à routeur dans IPv6
Statut de ce mémoire
Ce document spécifie un protocole de suivi des normes Internet pour la communauté Internet, et demande des discussions et des suggestions pour son amélioration. Veuillez vous référer à l'édition actuelle des "Normes officielles du protocole Internet" (STD 1) pour l'état de normalisation et le statut de ce protocole. La distribution de ce mémoire n'est soumise à aucune restriction.
Copyright
Copyright (C) The Internet Society (2005).
Résumé
L'algorithme d'envoi conceptuel IPv6 d'origine ne fait pas de partage de charge entre des routeurs IPv6 équivalents et suggère des schémas qui peuvent être problématiques dans la pratique. Ce document met à jour l'algorithme d'envoi conceptuel de la RFC 2461 afin que le trafic vers différentes destinations puisse être réparti entre les routeurs de manière efficace.
1. Introduction
Dans l'algorithme d'envoi conceptuel de la [RFC2461] et dans l'extension facultative de la [RFC4191], un bond suivant est choisi lorsque aucune entrée d'antémémoire de destination n'existe pour une destination hors liaison ou lorsque la communication via un routeur existant échoue. Normalement, un routeur est sélectionné la première fois que le trafic est envoyé à une adresse IP de destination spécifique. Le trafic ultérieur vers la même adresse de destination continue d'utiliser le même routeur, sauf s'il existe une raison de passer à un autre routeur (par exemple, un message de redirection est reçu, ou le routeur s'avère inaccessible).
De plus, comme décrit dans la [RFC3484], le choix du prochain bond peut également affecter le choix de l'adresse source, et donc indirectement (et dans une moindre mesure) peut également affecter le routeur utilisé pour le trafic entrant.
Dans l'algorithme d'envoi de base et dans l'extension facultative, un hôte a parfois le choix entre plusieurs routeurs équivalents pour une destination. Autrement dit, tous les autres facteurs sont égaux et un hôte doit faire un départage via des moyens spécifiques de la mise en œuvre.
Cela est souvent souhaitable lorsqu'il existe plusieurs routeurs équivalents et que les hôtes répartissent leur trafic sortant entre ces routeurs. Cela partage la charge entre plusieurs routeurs et offre de meilleures performances pour le trafic de l'hôte.
D'un autre côté, le partage de charge peut être indésirable dans les situations où une capacité suffisante est disponible via un seul routeur et les modèles de trafic pourraient être plus prévisibles en utilisant un seul routeur; en particulier, cela aide à diagnostiquer les problèmes de connectivité au-delà des routeurs de premier bond.
La [RFC2461] n'exige aucun comportement particulier à cet égard. Elle spécifie qu'une mise en œuvre peut toujours choisir le même routeur (par exemple, le premier de la liste) ou peut parcourir les routeurs de manière circulaire. Ces deux suggestions sont problématiques.
De toute évidence, toujours choisir le même routeur ne fournit pas de partage de charge. Certains problèmes avec le partage de charge utilisant des techniques de départage naïves telles que le tourniquet et l'aléatoire sont discutés dans la [RFC2991]. Bien que l'antémémoire de destination offre une certaine stabilité car la détermination ne se fait pas par paquet, des purges d'antémémoire ou des fins de temporisation peuvent toujours entraîner des chemins instables ou
page - 1 -
RFC4311 Partage de charge d'hôte à routeur dans IPv6 Hinden & Thaler imprévisibles au fil du temps, ce qui réduit les performances et rend plus difficile le diagnostic des problèmes. La
sélection à tour de rôle peut également entraîner des problèmes de synchronisation entre les hôtes, où dans le pire des cas, la charge est concentrée sur un routeur à la fois.
Dans le reste de ce document, les mots clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" doivent être interprétés comme décrit dans la [RFC2119].
2. Partage de charge
Lorsqu'un hôte choisit parmi plusieurs routeurs équivalents, il DEVRAIT prendre en charge le choix d'une méthode qui répartit la charge pour différentes destinations entre les routeurs équivalents plutôt que de toujours choisir le même routeur (par exemple, le premier de la liste). Ce mémoire ne prend aucune position quant à savoir si la prise en charge du partage de charge doit être activée ou désactivée par défaut. De plus, un hôte qui tente de répartir la charge entre les routeurs DEVRAIT utiliser un schéma fondé sur le hachage qui prend en compte (au moins) l'adresse IP de destination, comme celui décrit dans la [RFC2991], pour choisir un routeur à utiliser.
Noter que le trafic pour une adresse de destination donnée utilisera le même routeur tant que l'entrée d'antémémoire de destination pour l'adresse de destination n'est pas supprimée. Avec un schéma fondé sur le hachage, le trafic pour une certaine adresse de destination va utiliser le même routeur même si l'entrée d'antémémoire de destination est supprimée, tant que la liste des routeurs équivalents reste la même.
3. Considérations sur la sécurité
Comme mentionné dans la [RFC2991], quand le choix du prochain bond est prévisible, une application peut synthétiser le trafic qui va être haché de la même façon, rendant possible le lancement d'une attaque de déni de service contre l'algorithme de partage de charge, et surcharger un routeur particulier. Cela peut même être fait par une application distante qui peut amener un hôte à répondre à une adresse de destination donnée. Un cas particulier de cela est quand le même (seul) prochain bond est toujours choisi, comme dans le cas de l'algorithme permis par la [RFC2461]. Introduire le hachage peut rendre une telle attaque plus difficile ; plus le hachage est imprévisible, plus il est difficile de mener à bien une attaque de déni de service contre tout routeur.
Cependant une application locale malveillante peut outrpasser l'algorithme pour son propre trafic en utilisant des mécanismes comme des prises brutes, et des attaquants distants peuvent toujours surcharger les routeurs directement.
Donc, les mécanismes discutés ici n'ont pas d'impact incrémentaire significatif sur la sécurité de l'infrastructure de l'Internet.
4. Remerciements
Les auteurs de ce document tiennent à remercier Erik Nordmark, Brian Haberman, Steve Deering, Aron Silverton, Christian Huitema, et Pekka Savola.
5. Références normatives
[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.
(MàJ par RFC8174)
[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.)
[RFC3484] R. Draves, "Choix d'adresse par défaut pour le protocole Internet version 6 (IPv6)", février 2003.
(Remplacée par la RFC6724) (P.S.)
[RFC4191] R. Draves, D. Thaler, "Préférences en matière de routeur par défaut et chemins plus spécifiques",
page - 2 -
RFC4311 Partage de charge d'hôte à routeur dans IPv6 Hinden & Thaler novembre 2005. (P.S.)
6. Références pour information
[RFC2991] D. Thaler, C. Hopps, "Problèmes du multichemin dans le choix du prochain bon en envoi individuel et en diffusion groupée", novembre 2000. (Information)
Adresse des auteurs
Robert Hinden Dave Thaler
Nokia Microsoft Corporation
313 Fairchild Drive One Microsoft Way
Mountain View, CA 94043 Redmond, WA 98052
téléphone : +1 650 625-2004 téléphone : +1 425 703 8835
mél : bob.hinden@nokia.com mél : dthaler@microsoft.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.
page - 3 -
