Common address redundancy protocol

Common Address Redundancy Protocol ou CARP est un protocole permettant à un groupe d'hôtes sur un même segment réseau de partager une adresse IP. Le nom CARP est en fait un sigle signifiant « Common Address Redundancy Protocol » (Protocole Commun De Redondance D'Adresse) à ne pas confondre avec « Cache Array Routing Protocol » utilisé pour faire du load balancing de web proxy caches (voir RFC 3040).

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

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 membres 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 à l'attention de cette adresse. Chaque hôte peut appartenir à plusieurs groupes de redondance. Chaque hôte doit avoir une seconde adresse IP unique.

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

Vers la fin des années 90 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 avoir été raisonnable et non discriminatoire. Pour contourner le brevet de HSRP, ils ont assuré que CARP était fondamentallement 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 octobre 2003.

Voir aussi

• pfsync

Liens externes

• (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