Common Address Redundancy Protocol
Common Address Redundancy Protocol ou CARP (à ne pas confondre avec « Cache Array Routing Protocol ») est un protocole permettant à un groupe d'hôtes sur un même segment réseau de partager une adresse IP. Il peut être utilisé pour faire de la répartition de charge de mandataires caches web (voir RFC 3040) ou pour avoir de la tolérance de panne sur des routeurs sans avoir besoin de mettre en place des protocoles de routage dynamique.
CARP est une alternative sécurisée et libre aux protocoles Virtual Router Redundancy Protocol (VRRP), Hot Standby Router Protocol (HSRP) et Foundry Standby Router Protocol (FSRP). Il a été créé pour contourner des brevets. Ce protocole peut être utilisé pour faire de la redondance et de la répartition de charge.
CARP supporte IPv4 et IPv6, et a le numéro de protocole 112. Il est supporté par OpenBSD (3.5), FreeBSD (sur la branche 5 à partir de la 5.4 et aussi en 6.0), et NetBSD (4.0). Il peut être utilisé sous Linux via UCARP (en espace utilisateur).
Principe de la redondance
[modifier | modifier le code]On appelle un groupe d'hôtes utilisant CARP un « groupe de redondance ». Le groupe de redondance se voit attribuer une adresse IP partagée entre les membres du groupe. Au sein de ce groupe, un hôte est désigné comme « maître », les autres sont appelés « esclaves ». L'hôte maître est celui qui « prend » l'adresse IP partagée. Il répond à tout trafic ou requête ARP à destination de cette adresse. Chaque hôte doit avoir une seconde adresse IP unique. Chaque hôte peut appartenir à plusieurs groupes de redondance.
Une utilisation commune de CARP est la création d'un groupe de pare-feu redondants. L'adresse IP virtuelle attribuée au groupe de redondance est désignée comme l'adresse du routeur par défaut sur les machines clientes. Dans le cas où le pare-feu maître rencontre une panne ou est déconnecté du réseau, l'adresse IP virtuelle sera prise par un des pare-feu esclaves et le service continuera à être rendu sans interruption.
Historique
[modifier | modifier le code]Vers la fin des années 1990, l'IETF a commencé à travailler à une solution au problème. En 1997, Cisco les a informés que ceci avait déjà été couvert par ses brevets. En 1998, Cisco leur a indiqué qu'il avait été couvert par leur brevet de HSRP (Hot Standby Router Protocol). Néanmoins, l'IETF a continué le travail sur VRRP (Virtual Router Redundancy Protocol : protocole de redondance sur des routeurs virtuels). Après une discussion, il a été décidé que des technologies brevetées pouvaient être intégrées dans une norme, tant que cela reste conforme aux conditions de RAND (Reasonable and Non-Discrimatory, raisonnable et non-discriminatoire). Puisque VRRP a corrigé les problèmes du HSRP, Cisco a commencé à utiliser VRRP à la place, tout en le déclarant comme étant le sien.
Cisco a informé les développeurs d'OpenBSD qu'ils imposeraient leur brevet de HSRP. Ceci a certainement été lié avec leur procès contre Alcatel. Ainsi, une utilisation libre de VRRP aurait été impossible. Les développeurs d'OpenBSD ont commencé l'étude de CARP comme une alternative au VRRP breveté, car RAND ne leur semblait pas conforme à l'Open Source Definition. Pour contourner le brevet de HSRP, ils ont assuré que CARP était fondamentalement différent. En raison de l'orientation d'OpenBSD sur la sécurité, CARP a été conçu avec la sécurité comme principale ligne de conduite, et est conçu pour utiliser la cryptographie. Il est devenu disponible, complètement libre, en .
Voir aussi
[modifier | modifier le code]Liens externes
[modifier | modifier le code]- (en) UCARP : Protocole CARP en espace utilisateur, fonctionne sous Linux (2.4 et 2.6), OpenBSD et NetBSD.
- (en) Firewall Failover with pfsync and CARP, article de Ryan McBride
- (en) Fil de discussion, sur kerneltrap.org, sur CARP durant son développement dans OpenBSD
- (fr) Haute-disponibilité des pare-feux avec CARP et pfsync
