Aller au contenu

RIPE Network Coordination Centre

Un article de Wikipédia, l'encyclopédie libre.
(Redirigé depuis RIPE NCC)
RIPE Network Coordination Centre
Histoire
Fondation
Cadre
Zone d'activité
Type
Siège
Pays
Organisation
Site web
Logo du RIPE NCC

Le RIPE NCC (Réseaux IP Européens - Network Coordination Centre) est un registre régional d'adresses IP. Il dessert l'Europe et une partie de l'Asie, notamment au Moyen-Orient.

C'est une organisation à but non lucratif de droit néerlandais et son siège est à Amsterdam. Ses membres sont des opérateurs réseaux et fournisseurs de service Internet.

Quand on parle de RIPE tout court, on fait en général référence au rassemblement informel des acteurs européens de l'Internet. Ces acteurs se réunissent deux fois par an. Le RIPE NCC est une organisation qui assure notamment les fonctions de registre et le soutien logistique et administratif au RIPE.

Les membres du RIPE NCC sont appelés les Local Internet Registries (LIR), le RIPE NCC lui-même étant un des cinq Regional Internet Registries (RIR). Les LIR sont liés contractuellement au RIPE NCC par le RIPE NCC Standard agreement, et ils s'acquittent d'une cotisation annuelle.

Le RIPE NCC, comme les autres RIR, distribue les ressources internet :

  • les adresses IPv4,
  • les adresses IPv6,
  • les numéros d'Autonomous System (ASN) utilisés pour le routage entre opérateurs (utilisation du protocole BGP).

Il maintient également le moteur de la base de données publique (Routing Registry)[1]. La mise à jour des informations est du ressort des LIR.

Le RIPE NCC ne traite pas des noms de domaines, sauf dans le cadre de la délégation DNS inverse, car celle-ci est fondamentalement attachée à la distribution des adresses IP.

Distribution des adresses IPv4

[modifier | modifier le code]

Le 25 novembre 2019, le registre régional d’adresses IP qui alloue les IPv4 pour l’Europe et le Moyen-Orient annonce la pénurie d’IPv4, la dernière attribution du dernier bloc de 1024 adresses ayant été effectuée[2].


Distribution hiérarchisée

[modifier | modifier le code]

La distribution est faite en plusieurs niveaux :

  • l'IANA alloue aux RIR, dont le RIPE NCC, des blocs d'adresses IP très importants, de taille /8 (16 millions d'adresses) ou plus. Un RIR mettra 6 à 18 mois pour épuiser cette réserve ;
  • le RIPE NCC alloue aux LIR des blocs de taille variable, mais au moins /24 soit 256 adresses. Un LIR qui a des besoins réguliers importants recevait des allocations plus grandes, lorsque les réserves d'IPv4 le permettaient encore ;
  • les LIR affectent aux utilisateurs finaux des blocs, dont la taille correspond aux besoins immédiats et concrètement anticipés.

Les allocations des blocs d'adresses aux LIR permettent d'agréger les tables de routage (seuls les préfixes alloués sont visibles dans la table de routage). L'emploi par un utilisateur final requiert cependant une affectation à cet utilisateur, cette affectation fait l'objet d'un enregistrement dans la base de données publique du RIPE NCC et est soumise aux politiques du RIPE.

Vérification de la justesse des affectations

[modifier | modifier le code]

Le LIR reçoit des demandes d'adresses IP de la part de ses clients. Les affectations sont normalement traitées par le service hostmaster du RIPE NCC en application des politiques décrites dans les documents du RIPE. Chaque LIR dispose cependant d'une fenêtre d'affectation qui lui permet de traiter directement les demandes ne dépassant pas une certaine taille. La taille de la fenêtre d'affectation varie en fonction de l'activité du LIR et de son ancienneté, et elle peut être réduite à zéro, par exemple à la suite d'un audit du RIPE NCC qui indique que les procédures n'ont pas été respectées dans le passé.

Le LIR doit également suivre la procédure d'affectation pour ses besoins propres.

Adresses IPv4 PI et PA

[modifier | modifier le code]

La plupart des utilisateurs finaux reçoivent leurs adresses IP de leur fournisseur d'accès. Le fournisseur d'accès affecte un bloc issu d'une allocation plus grande qu'il a lui-même reçue du RIPE NCC. Ces adresses IP sont dites Provider Aggregatable ou PA, ce qui signifie que leur routage est agrégé sur l'internet par le fournisseur d'accès. Si l'utilisateur final change de fournisseur d'accès, il perd l'usage de ces adresses IP, et doit en demander d'autres à son nouveau fournisseur d'accès. Les adresses de type PA ne sont donc pas portables, mais elles permettent de contenir la croissance de la table de routage Internet.

Dans certains cas, quand un utilisateur souhaite avoir des adresses IP qui ne dépendent pas d'un fournisseur, il fait une demande d'adresses IP Provider Independant ou PI. C'est le cas si l'utilisateur dispose de connexions à plusieurs fournisseurs d'accès à Internet. Ces adresses sont toujours affectées directement par le RIPE NCC, au cas par cas. Chaque bloc PI nécessite une route spécifique dans la table de routage mondiale. Pour permettre la diffusion normale de la route sur Internet, un bloc PI ne devrait pas être plus petit que /24 soit 256 adresses IPv4. En effet, la plupart des routeurs, pour éviter de se surcharger la mémoire, refusent les routes trop précises.

Distribution des adresses IPv6

[modifier | modifier le code]

Les critères pour recevoir du RIPE NCC une allocation initiale sont :

  • être un LIR, c'est-à-dire un membre du RIPE NCC ;
  • les faire router (par le protocole BGP) en une seule route agrégée ;
  • prévoir de faire des sous-allocations ou des affectations.

La distribution se fait également à deux niveaux allocation/affectation.

Distribution des numéros d'AS

[modifier | modifier le code]

Un LIR peut demander un numéro d'AS pour lui-même ou pour un de ses clients. Le critère d'affectation d'un numéro d'AS est de pouvoir faire la preuve d'une politique de routage originale (c'est-à-dire qui ne peut pas être assimilée à celle d'un fournisseur de transit internet amont), faisant intervenir au moins deux interconnexions avec des réseaux (AS) tiers, en BGP4.

Les numéros d'AS sont historiquement codés sur 16 bits, ce qui fait qu'il en existe 65536. Les 1024 derniers sont réservés pour l'usage privé (de façon similaire aux IP définies par la RFC 1918[3]).

Pour faire face à l'épuisement de la réserve mondiale de numéros d'AS (en 2008, le RIPE NCC affectait au-delà du 47 000), les numéros d'AS à 32 bits ont été mis en place, ce qui a conduit à la politique suivante :

  • En 2008 et avant, lors d'une demande de numéro d'AS, le RIPE NCC affectait par défaut un numéro 16 bits, et affectait un numéro 32 bits sur demande explicite;
  • En 2009, la situation était inversée : numéro 32 bits par défaut, il fallait demander explicitement pour avoir encore un numéro d'AS 16 bits;
  • Depuis le , les numéros d'AS 16 et 32 bits sont traités dans un pot commun.

Un LIR qui se verrait affecter un numéro d'AS sur 32 bits doit disposer d'une version logicielle de routeur qui supporte cette extension. Il est cependant possible de traverser des groupes de routeurs qui ne connaissent pas les AS sur 32 bits, ce qui permet un déploiement progressif de cette extension.

Dans les numéros d'AS, il y a également une notion d'allocation/affectation :

  • le IANA alloue aux RIR dont le RIPE des blocs de 1024 numéros d'AS;
  • le RIPE NCC et les autres RIR affectent les numéros d'AS à l'unité, au cas par cas.

Politique de distribution des adresses IP

[modifier | modifier le code]

La distribution des adresses IP doit trouver un compromis entre deux buts contradictoires :

  • distribuer le moins possible d'adresses IP, car celles-ci sont en quantité limitée. Ce qui implique des affectations au cas par cas, plus nombreuses et basées sur les besoins immédiats démontrés. La conséquence est une fragmentation de l'espace d'adressage, avec une croissance du nombre de routes qui compose Internet (Internet comprend plus de 300 000 routes fin 2009);
  • favoriser l'agrégation de l'espace d'adressage, ce qui permet de préserver la compacité de la table de routage mondiale, mais oblige à faire des réservations donc à laisser des trous dans l'espace d'adressage et à anticiper les besoins.

Dans la distribution des adresses IPv4, dont les réserves sont prévues pour s'épuiser vers 2011 (et que s'est-il passé depuis ?), c'est le but de préservation des adresses IP qui est favorisé. Dans la distribution des adresses IPv6, c'est au contraire l'agrégation qui est favorisée, avec une distribution d'emblée d'un /32 à chaque LIR qui le demande.

En IPv4 par exemple, la politique en vigueur pour une affectation est la suivante[4] :

  • d'utiliser au moins 25 % de l'affectation immédiatement ;
  • d'utiliser au moins 50 % de l'affectation après un an ;
  • la réservation d'adresse est interdite (c'est-à-dire qu'une affectation doit concerner un besoin immédiat) ;
  • si une affectation concerne une renumérotation, on considère qu'un délai de recouvrement de 3 mois convient entre la nouvelle affectation et la libération de l'ancien bloc d'adresses ;
  • la taille d'une affectation ne se justifie que par le nombre d'appareils nécessitant une adresse IPv4 :
    • il n'est pas possible de demander plus d'adresses IP pour une raison administrative (par exemple : un /24 soit 256 adresses par site pour simplifier la gestion des adresses)
    • ni même pour une raison de routabilité (cf ci-dessus, PA versus PI)
  • les technologies permettant d'économiser l'utilisation d'adresses sont encouragées :
    • translation d'adresses et utilisation des IP privées selon la RFC 1918 ;
    • pour les hébergeurs web, utilisation des noms virtuels qui permettent d'avoir des sites web aux URL différentes sur le même serveur, donc avec une seule adresse IP.

En IPv6, les critères sont beaucoup plus souples, et le critère d'affectation ne tient pas compte de la nécessité réelle en nombre d'adresses. En IPv6, les réseaux locaux disposent d'un sous-réseau de taille /64, ce qui permet 264 stations sur chaque segment du réseau[5].

Les relations entre le RIPE NCC et les LIR

[modifier | modifier le code]

Les communications sont habituellement effectuées par courriel, de même que les mises à jour de la base RIPE, sur une boite gérée par un robot qui reconnait les formulaires (fichiers textes).

Les demandes d'approbation/affectation/allocation sont traitées d'abord par un robot, puis sont évaluées par un hostmaster, un employé du RIPE NCC. Les demandes sont traitées en quelques jours, pour autant que la documentation prévue soit présente.

Autres activités

[modifier | modifier le code]

Le RIPE NCC organise régulièrement des journées de formation dans les grandes villes européennes pour ses nouveaux membres.

Outils divers

[modifier | modifier le code]

Le RIPE NCC propose des outils dont certains sont accessibles au public sur son site web. Ces outils sont utiles aux opérateurs de réseaux IP pour vérifier le bon fonctionnement de leur routage externe BGP, pour aider à la gestion des adresses publiques, pour la vérification de performances du réseau. Parmi les outils publics nous pouvons citer le projet ATLAS[6].

Serveur DNS racine

[modifier | modifier le code]

Le RIPE NCC a la responsabilité d'un des 13 serveurs racine du DNS, le k.root-servers.net. Ce serveur est désormais compatible IPv6 (tous les DNS racine ne le sont pas encore). Il est déployé en utilisant la technologie anycast, c'est-à-dire que plusieurs machines physiques réparties géographiquement assurent le service, et que le routage Internet détermine celle qui traite la demande d'un client déterminé[7].

Gestion de la zone DNS ENUM

[modifier | modifier le code]

Le RIPE NCC gère pour la communauté mondiale la zone DNS ENUM e164.arpa. Cette branche de l'arborescence DNS globale a pour vocation d'intégrer des numéros de téléphone dans l'arborescence DNS. Ainsi, la zone 3.3.e164.arpa correspondant au préfixe téléphonique français « +33 » a été déléguée par le RIPE à l'Afnic, qui gère déjà pour la France les noms de domaines en « .fr »[8].

Autres registres régionaux

[modifier | modifier le code]

Les autres registre régionaux d'adresses IP sont les suivants :

Les RIR reçoivent eux-mêmes les ressources de l'IANA.

Notes et références

[modifier | modifier le code]

Liens externes

[modifier | modifier le code]