Cette section examine plusieurs algorithmes de recherche de chemin qui sont utilisés ou ont été proposés. Chacun d’eux est décrit en donnant la séquence des règles d’élagage qu’il utilise. Les forces et faiblesses de chaque algorithme sont présentées.
E.3.1 Algorithme classique révisé
L’algorithme classique révisé est la forme de l’algorithme traditionnel qui a été exposé au paragraphe E.1. Les étapes de cet algorithme sont :
1. Correspondance de base 2. Plus longue correspondance 3. Meilleure métrique
4. Politique
Certaines des mises en œuvre omettent l’étape de politique, car elle n’est nécessaire que lorsque des chemins pourraient avoir des métriques qui ne sont pas comparables (parce qu’ils ont été acquis auprès de domaines d’acheminement différents).
Les avantages de cet algorithme sont : (1) Il est largement mis en œuvre
(2) Excepté pour l’étape de politique (qu’une mise en œuvre peut choisir de rendre arbitrairement complexe) l’algorithme est simple à comprendre et à mettre en œuvre.
Ses inconvénients sont :
(1) Il ne traite pas les classes de chemin IS-IS ou OSPF, et donc ne peut pas être utilisé pour IS-IS intégré ou OSPF.
(2) Il ne traite pas le TOS ou autres attributs de chemin.
(3) Les mécanismes de politique ne sont pas du tout normalisés, et ils sont donc souvent spécifiques de la mise en œuvre. Cela cause un travail supplémentaire aux développeurs (qui doivent inventer des mécanismes de politique appropriés) et aux utilisateurs (qui doivent apprendre à utiliser le mécanisme. Cette absence d’un mécanisme normalisé rend aussi difficile la construction de configurations cohérentes pour les routeurs provenant de différents fabricants. Cela présente un obstacle pratique significatif à l’interopérabilité.
(4) Le mécanisme de politique propriétaire actuellement fourni par les fabricants est souvent inadéquat dans des parties complexes de l’Internet.
(5) L’algorithme n’a pas été rédigé dans un document ou norme disponible au public. Il fait parie du folklore de l’Internet.
E.3.2 Variante de l’algorithme des exigences de routeur
Certains membres du groupe de travail Exigences pour les routeurs ont proposé une légère variante de l’algorithme décrit au paragraphe 5.2.4.3. Dans cette variante, la correspondance avec le type de service demandé n’est pas considérée comme plus importante, et plutôt moins importante, que de correspondre autant que possible à l’adresse de destination. Par exemple, cet algorithme préfèrerait un chemin par défaut qui a le type de service correct à un chemin de réseau qui aurait le type de service par défaut, alors que l’algorithme du paragraphe 5.2.4.3 ferait le choix opposé.
Les étapes de l’algorithme sont : 1 Correspondance de base 2 TOS faible
3 Plus longue correspondance 4 Meilleure métrique
5 Politique
Le débat entre ceux qui proposent cet algorithme et les partisans de l’algorithme des exigences de routeur suggère que chaque camp peut montrer des cas où son algorithme conduit à un acheminement plus simple, plus intuitif que ne le fait l’autre algorithme. Cette variante a le même ensemble d’avantages et d’inconvénients que l’algorithme spécifié en 5.2.4.3, excepté que l’élagage sur le TOS faible avant l’élagage sur la plus longue correspondance rend cet algorithme moins compatible avec OSPF et IS-IS intégré que l’algorithme des exigences de routeur standard.
E.3.3 Algorithme OSPF
OSPF utilise un algorithme qui est virtuellement identique à l’algorithme des exigences de routeur excepté sur un point crucial : OSPF prend en compte les classes d’acheminement OSPF.
L’algorithme est :
1 Correspondance de base 2 Classe d’acheminement OSPF 3 Plus longue correspondance 4 TOS faible
5 Meilleure métrique 6 Politique
La prise en charge du type de service n’est pas toujours présente. Si elle ne l’est pas, bien sûr, la quatrième étape sera omise.
Cet algorithme a quelques avantages sur l’algorithme classique révisé : (1) Il prend en charge l’acheminement par type de service.
(2) Ses règles sont écrites, plutôt que de faire simplement partie du folklore Internet.
(3) Il travaille (évidemment) avec OSPF.
Cependant, cet algorithme conserve certains des inconvénients de l’algorithme classique révisé : (1) Les propriétés de chemin autres que le type de service (par exemple, la MTU) sont ignorées.
(2) Comme dans l’algorithme classique révisé, les détails (ou même l’existence) de l’étape Politique sont laissés à la discrétion de la mise en œuvre.
L’algorithme OSPF a encore un autre inconvénient (qui n’est pas partagé par l’algorithme classique révisé). Les chemins internes OSPF (intra zone ou interzone) sont toujours considérés comme supérieurs aux chemins appris d’autres protocoles d’acheminement, même dans les cas où le chemin OSPF correspond par moins de bits à l’adresse de
destination. C’est une décision de politique qui est inappropriée dans certains réseaux.
Finalement, il vaut de noter que la prise en charge du TOS par l’algorithme OSPF souffre d’une faiblesse en ce que les protocoles d’acheminement qui prennent en charge le TOS sont implicitement préférés lors de la transmission de paquets qui ont des valeurs de TOS différentes de zéro. Cela peut n’être pas approprié dans certains cas.
E.3.4 Algorithme IS-IS intégré
IS-IS intégré utilise un algorithme qui est similaire mais pas tout à fait identique à l’algorithme OSPF. IS-IS intégré utilise un ensemble de classes d’acheminement différent, et diffère légèrement dans le traitement du type de service.
L’algorithme est :
1 Correspondance de base 2 Classes d’acheminement IS-IS 3 Plus longue correspondance 4 TOS faible
5 Meilleure métrique 6 Politique
Bien que IS-IS intégré utilise le TOS faible, le protocole n’est capable que de porter des chemins pour un petit sous-ensemble spécifique des valeurs possible pour le champ TOS dans l’en-tête IP. Les paquets qui contiennent d’autres valeurs dans le champ TOS sont acheminés en utilisant le TOS par défaut.
La prise en charge du type de service est facultative ; si elle est désactivée, la quatrième étape sera omise. Comme dans OSPF, la spécification n’inclut pas l’étape de politique.
Cet algorithme présente quelques avantages sur l’algorithme classique révisé : (1) Il prend en charge l’acheminement par le type de service.
(2) Ses règles sont écrites, plutôt que de simplement faire partie du folklore de l’Internet.
(3) Il travaille (évidemment) avec IS-IS intégré.
Cependant, cet algorithme conserve aussi certains des inconvénients de l’algorithme classique révisé : (1) Les propriétés de chemin autres que le type de service (par exemple, MTU) sont ignorées.
(2) Comme dans l’algorithme classique révisé, les détails (ou même l’existence) de l’étape de politique sont laissés à la discrétion de la mise en œuvre.
(3) Il ne travaille pas avec OSPF à cause des différences entre les classes d’acheminement IS-IS et les classes d’acheminement OSPF. Et aussi, parce que IS-IS ne prend en charge qu’un sous ensemble des valeurs de TOS possibles, certaines mises en œuvre évidentes de l’algorithme IS-IS intégré n’accepteraient pas l’interprétation du TOS d’OSPF.
L’algorithme IS-IS intégré a aussi d’autres inconvénients (qui ne sont pas partagés par l’algorithme classique révisé) : les chemins internes IS-IS (intra zone ou interzone) sont toujours considérés comme supérieurs aux chemins appris d’autres protocoles d’acheminement, même dans les cas où le chemins IS-IS correspond à moins de bits de l’adresse de destination et ne fournit pas le type de service demandé. C’est une décision de politique qui peut n’être pas appropriée dans tous les cas.
Finalement, il vaut de noter que la prise en charge du TOS par l’algorithme IS-IS intégré souffre de la même déficience que celle notée pour l’algorithme OSPF.
Considérations sur la sécurité
Bien que l’objet du présent document soit l’interopérabilité plutôt que la sécurité, de nombreux paragraphes du présent document ont des rapports évidents avec la sécurité du réseau.
Sécurité signifie des choses différentes selon les individus. Du point de vue d’un routeur, la sécurité est tout ce qui aide à garder opérationnel son propre réseau et en plus aide à garder l’Internet en bonne santé dans son ensemble. Pour les besoins du présent document, les services de sécurité qui nous importent sont le déni de service, l’intégrité, et l’authentification lorsqu’elle s’applique aux deux premiers. La confidentialité est importante comme service de sécurité, mais elle n’est qu’une préoccupation périphérique pour un routeur – au moins au jour de la rédaction du présent document.
Divers endroits du présent document possèdent des paragraphes intitulés Considérations sur la sécurité. Ces paragraphes exposent les considérations spécifiques qui s’appliquent au sujet général exposé.
Le présent document indique rarement "Faites ceci et votre routeur/réseau sera en sécurité". Plus vraisemblablement, il dit ceci est une bonne idée et si vous le faites cela *peut* améliorer la sécurité de l’Internet et de votre système local en général.
Malheureusement, ceci est l’état de l’art AU MOMENT PRÉSENT. Peu, s’il en est, de protocoles de routeur du réseau se soucient d’avoir des dispositifs de sécurité raisonnables incorporés. L’industrie et les concepteurs de protocoles ont été et continuent d’être en dispute sur ces questions. Il y a des progrès, mais très petits, comme l’authentification d’homologue à homologue disponible dans les protocoles d’acheminement BGP et OSPF.
En particulier, le présent document note les recherches actuelles pour développer et améliorer la sécurité du réseau. Des domaines de recherche spécifiques, des développements, et de l’ingénierie sont en bonne voie au moment de la rédaction (décembre 1993) dans la sécurité d’IP, la sécurité SNMP, et les technologies communes d’authentification . Malgré ce qui précède, il y a des choses que les fabricants et les utilisateurs peuvent faire pour améliorer la sécurité de leur routeur. Les fabricants devraient avoir une copie de Trusted Computer System Interpretation [INTRO:8]. Même si un fabricant décide de ne pas soumettre son appareil à une vérification formelle selon ces lignes directrices, la publication donne d’excellents conseils sur la conception générale sur les pratiques de la sécurité pour le matériel informatique.
Appendice F Protocoles d'acheminement historiques
Certains protocoles d’acheminement sont courants sur l’Internet, mais les auteurs du présent document ne peuvent en conscience recommander leur utilisation. Ce n’est pas parce qu’ils ne fonctionnent pas correctement, mais parce que les caractéristiques de l’Internet supposées dans leur conception (acheminement simple, pas de politique, un réseau à un seul "routeur central" sous administration commune, complexité limitée, ou diamètre de réseau limité) ne sont pas des attributs de l’Internet d’aujourd’hui. Les parties de l’Internet qui les utilisent encore sont généralement des domaines
"marginaux" limités avec une faible complexité.
En témoignage de bonne foi, un recueil de conseils sur leur mise en œuvre est exposé dans cette section.
F.1 Protocole de passerelle extérieure - EGP