|
Détails |
|
1. Résumé du problème traité par cette proposition
AFRINIC a une politique existante pour faire IPv4 des affectations à l'infrastructure critique, mais pas une pour réserver spécifiquement un espace Internet Number Resources pour les IXP. En conséquence, il est prévu que l'épuisement de ces ressources pourrait rendre difficile, voire impossible, pour les IXP d'obtenir des ressources suffisantes pour croître.
2. Résumé de la manière dont cette proposition résout le problème
Cette politique demande à AFRINIC de réserver et de publier IPv4 les ressources, et ASNs à l'usage des IXP uniquement.
3. Proposition
3.1 Introduction
Il est communément admis que les points d'échange Internet (IXP) sont l'un des éléments essentiels nécessaires au développement des écosystèmes Internet. L'Afrique est toujours en train de développer des IXP et est en même temps confrontée à l'épuisement imminent de ses ressources IPv4.
Ne pas avoir IPv4 des adresses pour développer ou démarrer de nouveaux IXP créeraient une complexité de routage inutile et inutile pour les réseaux connectés à Internet, cherchant à regarder les IXP pour étendre leur réseau.
AFRINIC a déjà une politique existante pour faire des allocations aux IXP [1], mais cette politique ne réserve pas spécifiquement IPV4 espace pour s'assurer qu'il y en aura, pour que les futurs IXP se développent et se développent. De plus, cette politique réserve un ensemble de ASNs entre 0 et 65535 pour une utilisation par les IXP, pour les serveurs de routage IXP BGP.
3.2 Distinction entre l'appairage IXP et les réseaux de gestion
Nous distinguons deux types de ressources de numéros IP nécessaires et utilisés aux IXP.
Un LAN d'échange IXP est le bloc contigu d'adresses de réseau que l'IXP utiliserait pour attribuer des adresses IP uniques à chaque membre de peering pour permettre à chaque participant au peering d’échanger le trafic réseau à travers l'infrastructure de peering partagée. La meilleure pratique est de ne pas rendre visible le réseau LAN de l’IXP dans la table de routage globale, entre autres pour réduire les vecteurs d'attaque pour les routeurs de frontière ISP via l'IXP.
Du point de vue de l'identification, de la surveillance et de l'analyse d'un réseau, il est donc souhaitable que l'espace "LAN d'appairage" soit fourni à partir d'un bloc contigu. Le LAN de gestion de l'IXP est le réseau de gestion utilisé par l'IXP pour fournir des services sur l'IXP, comme la surveillance, les statistiques, le courrier, les systèmes de tickets, l'approvisionnement du transit vers les racines DNS, etc. Les réseaux de gestion sont censés être accessibles à l'échelle mondiale, par exemple pour publier des données et permettre l'accès à distance à une bonne infrastructure de réseau (comme les serveurs DNS racine et TLD) et à des projets de recherche.
3.3 Utilisation des serveurs de route BGP
Les IXP utilisent généralement des serveurs de routage BGP pour aider à gérer les sessions d'appairage entre différents participants. Les serveurs de routage mettent en œuvre la politique de routage IXP sous la forme de communautés BGP, généralement sous la forme A: B, où A, B représentent A = serveur de routage IXP BGP et B = participant ASN.
Les implémentations BGP actuelles utilisent 6 octets pour l'attribut de communauté étendue. Par conséquent, un IXP avec un octet 4 ASN en cours d'utilisation sur son serveur de routage ne serait pas en mesure de mettre en œuvre avec succès le mappage de communauté BGP A: B, si un participant IXP a un octet de 4 octets ASN. Cette situation est susceptible d'être vécue par plus d'IXP, comme 4 octets supplémentaires ASNs sont attribués dans le cadre du processus AFRINIC actuel.
Si les communautés de serveurs de routage IXP incluent l'ASN participant à l’IXP et l'ASN du pair (qui devrait être 4 octets) et que seulement 6 octets au total sont disponibles, l'ASN des serveurs de routage IXP ne pourra pas dépasser 2 octets.
3.4 Proposition
Pour s'assurer qu'il y ait suffisamment de ressources pour le fonctionnement des IXP, cette politique propose qu'AfriNIC réserve des adresses IPv4 pour les réseaux locaux de peering à partir d'un bloc d'adresses réservé particulièrement et exclusivement à l'utilisation du LAN d’échange IXP.
Les affectations pour les réseaux locaux homologues IXP doivent provenir d'un bloc dédié, publié comme tel par AFRINIC. Les attributions de Peering LAN pour chaque IXP doivent garantir que le bloc IP adjacent / 24 est réservé (sur la base de la taille minimale de la politique d'attribution de l'utilisateur final de / 24) pour prendre en charge la croissance future de l'IXP. Cela permettra à un IXP d'augmenter ses ressources LAN d'appairage à / 23 sans avoir à renuméroter vers une nouvelle allocation de bloc IP contiguë.
Les assignations d’adresses de gestion IXP NE DOIVENT PAS être effectuées à partir du même bloc que celui des LAN d’échange IXP.
Il est proposé qu'un bloc / 16 soit réservé pour les besoins futurs des réseaux locaux homologues IXP dans la région de service AFRINIC, et qu'AFRINIC publie ce bloc en tant que tel. De plus, les attributions pour le réseau local homologue IXP devraient réserver le bloc IP contigu / 24 adjacent au IXP demandeur pour une croissance future.
Ces réservations seront maintenues jusqu'à ce que le pool disponible des / 16 ne puisse plus attribuer / 23 affectations. Par la suite, de nouvelles demandes peuvent être attribuées à partir de l'espace réservé détenu pour la croissance future de l'IXP. Il est en outre proposé de réserver l'équivalent d'un bloc / 16 supplémentaire pour les préfixes de gestion IXP, distinct des réseaux locaux d'appairage.
Il est proposé que AFRINIC réserve un bloc de ASNs entre 0 et 65535 XNUMX pour une utilisation dans les serveurs de routage BGP des points IXP dans la région de service AFRINIC. Le nombre de ASNs à réserver doit être le plus élevé de 114, ou la moitié du reste ASNs entre 0 et 65535 dans le bloc d'AFRINIC à la date de ratification de cette politique. AFRINIC allouera ces ressources sur la base du premier arrivé, premier servi.
3.5 Critères d'évaluation
Cette politique ne suggère pas de nouveaux critères d'évaluation pour déterminer la validité d’un IXP.
4. Historique des révisions
- 23 oct. 2014 - AFPUB-2014-GEN-004-DRAFT- 01 posté on rpd liste.
- 05 nov. 2014 - AFPUB-2014-GEN-004-DRAFT- 02 Posté sur rpd liste.
- 11 juin 2015 - AFPUB-2014-GEN-004-DRAFT- 03 posté on rpd liste.
Bibliographie
[1] Politique AFRINIC pour les attributions d'utilisateurs finaux - AFPUB-2006-GEN-001, http://afrinic.net/en/library/policies/127-afpub-2006-gen-001 Sections (5) et (6)
