Reverse Address Resolution Protocol
Dans le monde d'aujourd'hui, Reverse Address Resolution Protocol est un sujet qui a acquis une grande importance et a retenu l'attention de différents secteurs de la société. Depuis son apparition, Reverse Address Resolution Protocol a marqué un avant et un après dans la façon dont nous interagissons, vivons et percevons le monde qui nous entoure. Au fil du temps, Reverse Address Resolution Protocol est devenu un sujet de débat et de discussion dans différents domaines, générant des opinions contradictoires et déclenchant des actions qui ont eu un impact sur la vie des gens. Il est donc crucial d’analyser et de comprendre en profondeur l’impact que Reverse Address Resolution Protocol a eu sur nos vies, ainsi que sur le développement de la société dans son ensemble. Dans cet article, nous explorerons certaines facettes de Reverse Address Resolution Protocol et son influence sur divers aspects de la vie quotidienne, afin de fournir une vision plus large et plus complète de ce sujet d'une importance vitale.
Cet article est une ébauche concernant l’informatique.
RARP (pour Reverse ARP) permet à partir d'une adresse matérielle (adresse MAC) de déterminer l'adresse IP d'une machine. En résumé, RARP (RFC 903) fait l'inverse de ARP (RFC 826).
A ne pas confondre avec le protocole Inverse ARP[1] (InARP) utilisé par les protocoles ATM ou Frame Relay, pour trouver aussi à partir d'une adresse de couche 2 du modèle OSI, une adresse de couche 3 du modèle OSI (RFC 2390).
Le protocole RARP (Reverse Address Resolution Protocol) est beaucoup moins utilisé, il signifie Protocole ARP inversé, il s'agit donc d'une sorte d'annuaire inversé des adresses logiques et physiques. En réalité le protocole RARP est essentiellement utilisé pour les stations de travail n'ayant pas de disque dur et souhaitant connaître leur adresse logique.
Le protocole RARP permet à une station de connaître son adresse IP à partir d'une table de correspondance entre adresse MAC (adresse physique) et adresses IP hébergée par une passerelle (gateway) située sur le même réseau local (LAN).
Pour cela il faut que l'administrateur paramètre le routeur avec la table de correspondance des adresses MAC/IP. En effet, à la différence de ARP, ce protocole est statique. Il faut donc que la table de correspondance soit toujours à jour pour permettre la connexion de nouvelles cartes réseau.
RARP souffre de nombreuses limitations. Il nécessite beaucoup de temps d'administration pour maintenir des tables importantes dans les serveurs. Cela est d'autant plus vrai que le réseau est grand. Cela pose les problèmes de la ressource humaine, nécessaire au maintien des tables de correspondance et des capacités des matériels hébergeant la partie serveur du protocole RARP. En effet, RARP permet à plusieurs serveurs de répondre à des requêtes, bien qu'il ne prévoit pas de mécanismes garantissant que tous les serveurs soient capables de répondre, ni même qu'ils répondent de manière identique. Ainsi, dans ce type d'architecture on ne peut avoir confiance en un serveur RARP pour savoir si à une adresse MAC peut être liée à une adresse IP parce que d'autres serveurs ARP peuvent avoir une réponse différente. Une autre limitation de RARP est qu'un serveur ne peut servir qu'un LAN.
Pour pallier les deux premiers problèmes d'administration, le protocole RARP peut être remplacé par le protocole DRARP, qui en est une version dynamique. Une autre approche, consiste à utiliser un serveur DHCP, qui lui, permet une résolution dynamique des adresses. De plus, DHCP est compatible avec le protocole BOOTP. Comme ce dernier il est routable ce qui permet de servir plusieurs LAN. Il ne marche qu'avec IP.
La principale documentation sur les protocoles ARP et RARP est constituée par les RFCs :
- RFC 826[2] - ARP (An Ethernet Address Resolution Protocol)
- RFC 903[3] - RARP (Reverse Address Resolution Protocol)
Références
- ↑ « What’s the difference between ARP, Reverse ARP, & Inverse ARP? », sur www.happyrouter.com (consulté le )
- ↑ (en) « An Ethernet Address Resolution Protocol », Request for comments no 826,
- ↑ (en) « A Reverse Address Resolution Protocol », Request for comments no 903,
