Déclaration d’applicabilité du protocole RIP version 2

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation 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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé
À la demande de la RFC 1264, Critères des protocoles d’acheminement, le présent rapport définit l’applicabilité du protocole RIP-2 au sein de l’Internet. Le présent rapport est une condition préalable de l’avancement de RIP-2 sur la voie de la normalisation.

1. Documentation du protocole

L’analyse du protocole RIP-2 est effectuée dans la RFC 1721 [1].

La description du protocole RIP-2 est définie dans la RFC 1723 [2]. Le présent mémoire rend obsolète la RFC 1388, qui spécifie une mise à jour du "Protocole d’informations d’acheminement" RFC 1058 (STD 34).

La description de la MIB de RIP-2 est définie dans la RFC 1724 [3]. Le présent mémoire rendra obsolète la RFC 1389.

2. Introduction

Le présent rapport décrit comment RIP-2 peut être utile au sein de l’Internet. Par nature, les environnements dans lesquels RIP-2 est le IGP choisi est un sur-ensemble des environnements dans lesquels RIP-1, tel que défini dans la RFC 1058 [1], a traditionnellement été utilisé. Il est important de se rappeler que RIP-2 est une extension de RIP-1 ; RIP-2 n’est pas un nouveau protocole. Et donc, les aspects opérationnels des protocoles d’acheminement à vecteur de distance, et RIP-1 en particulier, sont bien compris au sein d’un système autonome.

Il faut noter que RIP-2 n’est pas destiné à être un substitut de OSPF dans les grands systèmes autonomes; les restrictions sur le diamètre et la complexité d’un système autonome qui s’appliquaient à RIP-1 s’appliquent aussi à RIP-2. RIP-2 permet plutôt à un protocole à vecteur de distance plus petit et plus simple d’être utilisé dans des environnements qui exigent l’authentification ou l’utilisation de gabarits de sous-réseau de longueur variable, mais ne sont pas d’une taille ou d’une complexité qui exige l’utilisation d’un protocole d’état de liaison plus grand et plus complexe.

Le reste du présent rapport décrit comment chacune des extensions à RIP-1 peut être utilisée pour accroître l’utilité globale de RIP-2.

3. Applicabilité de l’extension

3.1 Gabarits de sous-réseau

L’élan d’origine de la création de RIP-2 était le désir d’inclure les gabarits de sous réseau dans les informations d’acheminement échangées par RIP. Cela était nécessaire à cause de l’absence de définition du sous-réseautage lors de la création de RIP. Tant que le gabarit de sous- réseau était fixé pour un réseau, et bien connu de tous les nœuds de ce réseau, une heuristique pouvait être utilisée pour déterminer si une route était une route de sous-réseau ou une route d’hôte. Avec l’avènement du sous-réseautage de longueur variable, CIDR, et du super-réseautage, il n’était plus possible à une heuristique de distinguer raisonnablement entre les routes de réseau, de sous-réseau, et d’hôte.

En utilisant le champ de 32 bits qui suit immédiatement l’adresse IP dans l’entrée d’acheminement RIP, il devient possible d’identifier positivement le type d’une route. En fait, on peut aller jusqu’à dire que l’inclusion du gabarit de sous-réseau crée effectivement une adresse de 64 bits qui éliminé la distinction entre réseau, sous-réseau et hôte.

Donc, l’inclusion des gabarits de sous-réseau dans RIP-2 lui permet d’être utilisé comme dans un AS qui exige une connaissance précise du gabarit de sous-réseau d’une route donnée, mais n’exige pas autrement OSPF.

3.2 Prochain bond

L’objet du champ Prochain bond est d’éliminer les paquets qui sont acheminés par des bonds supplémentaires dans le système. Il est particulièrement utile lorsque RIP ne fonctionne pas sur tous les routeurs d’un réseau. . Considérons l’exemple de la topologie suivante :

Les routeurs internes (IR1 et IR2) ne fonctionnent qu’avec RIP-2. Les routeurs externes (XR1 et XR2) fonctionnent tous deux avec BGP, par exemple ; cependant, seul XR1 fonctionne avec BGP et RIP-2. Comme XR2 ne fonctionne pas avec RIP-2, les IR ne connaissent pas son existence et ne s’en serviront jamais comme prochain bond, même si il est un meilleur prochain bond que XR1. Bien sûr, XR1 sait cela et peut indiquer, via le champ Prochain bond, que XR2 est le meilleur prochain bond pour certaines routes.

On a trouvé aussi une autre utilisation de Prochain bond. Considérons l’exemple de la topologie suivante :

Les trois liaisons entre le routeur de bureau central (COR, Central Office Router) et les routeurs de bureau distant (RO1 et RO2) sont toutes des liaisons d’appel à la demande (DOD, Dial-On-Demand). La liaison entre RO2 et R est une liaison fixe. Une fois que tous les routeurs ont été initialisés, les seules routes qu’ils connaissent sont les routes configurées de façon statique pour les liaisons DOD. Supposons que les connexions entre COR et RO1, et entre COR et RO2 soient établies et que les informations de RIP passent entre les routeurs. RO1 va ignorer la route de COR à RO2 parce qu’il en a déjà une meilleure ; cependant, il va apprendre à atteindre R via COR.

Si nous supposons que RO1 et RO2 sont seulement capables d’établir une liaison à la fois, RO1 ne sera alors pas capable d’atteindre RO2 ; cependant, RO1sera capable d’atteindre R. Pire encore, si nous supposons que le trafic s’arrête et que les liaisons DOD sont interrompues pour inactivité, une tentative de RO1 pour atteindre R va déclancher l’appel de deux liaisons (à travers COR). Bien sûr, une fois que RO1 aura établi une liaison avec RO2, le problème se corrige de lui-même parce que la nouvelle route pour R est plus courte d’un bond.

Pour corriger ce problème, les routeurs peuvent utiliser le champ Prochain bond pour indiquer leur prochain bond. Considérons les annonces de route suivantes durant la période décrite ci-dessus (avant que la liaison RO1/RO2 ait été établie) :

Lorsque R01 reçoit les deux routes de COR, il ignorera la route pour RO2, comme mentionné ci-dessus. Cependant, comme R n’est pas dans le tableau d’acheminement de RO1, il va l’ajouter en utilisant un prochain bond de RO2 (parce que RO2 est directement connecté, tant bien que mal). Noter que COR ne se compte pas lui-même dans la métrique de R ; ceci est moins que précis, mais entièrement sûr et corrigible (lorsque la liaison RO1/RO2 s’établit). Supposons maintenant que la liaison RO1/RO2 n’existe pas. RO1 ignorerait la spécification de RO2 comme prochain bond pour R et utiliserait COR, comme il l’aurait fait si aucun Prochain bond n’avait été spécifié.

Noter que ceci n’est pas un algorithme récursif ; il ne fonctionne que pour éliminer un seul bond de trop du chemin. Il n’y a pas de méthode pour étendre le mécanisme de façon à inclure une plus grande optimisation, mais le potentiel de création de boucles d’acheminement n’a pas été suffisamment analysé pour en spécifier une ici.

3.3 Authentification

Le besoin d’authentification dans un protocole d’acheminement est évident. Il n’est normalement pas important de dissimuler les informations des messages d’acheminement, mais il est essentiel d’empêcher l’insertion d’informations d’acheminement erronées dans les routeurs. Aussi, alors que le mécanisme d’authentification spécifié dans RIP-2 est loin d’être idéal, il empêche toute personne qui ne peut accéder directement au réseau (c’est-à-dire, quelqu’un qui ne peut pas espionner les paquets d’acheminement pour découvrir le mot de passe) d’insérer des informations d’acheminement erronées.

Cependant, la spécification permet que des types d’authentification supplémentaires soient incorporés dans le protocole. Malheureusement, à cause du format original des paquets de RIP, la quantité d’espace disponible pour fournir les informations d’authentification est seulement de 16 octets.

3.4 Diffusion groupée

Le protocole RIP-2 assure la diffusion groupée sur IP d’annonces périodiques. Ce dispositif a été ajouté pour diminuer la charge des systèmes qui ne prennent pas en charge RIP-2. Il fournit aussi un mécanisme par lequel les routeurs RIP-1 ne recevront jamais de routes RIP-2. C’est un dispositif qui sert lorsque l’utilisation correcte d’une annonce de route dépend de la connaissance du gabarit précis se sous-réseau, ce qui devrait être ignoré par un routeur RIP-1.

4 Conclusion

Parce que le protocole de base est inchangé, RIP-2 est un protocole d’acheminement aussi correct que RIP-1. Les améliorations font que RIP-2 est utile dans des environnements que RIP-1 ne peut pas traiter, mais qui ne nécessitent pas l’utilisation de OSPF en vertu des exigences que RIP-2 ne satisfait pas.

5. Références

[1] G. Malkin, "Analyse du protocole RIP version 2", RFC 1721, Xylogics, Inc., novembre 1994.

[2] G. Malkin, "RIP version 2 – Portage d’informations supplémentaires", RFC 1723, Xylogics, Inc., novembre 1994.

[3] G. Malkin et F. Baker, "Extension de la MIB de RIP version 2", RFC 1724, Xylogics, Inc., Cisco Systems, novembre 1994.

6. Considérations sur la sécurité

Les questions de sécurité ne sont pas abordées dans le présent mémoire.

7. Adresse de l’auteur

Gary Scott Malkin
Xylogics, Inc.
53 Third Avenue
Burlington, MA 01803
Téléphone : (617) 272-8140
mél : gmalkin@Xylogics.COM