Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

Guide Collectif des politiques (v1.6 actuelle)

Publié le
 

1.0 Introduction

Les politiques de gestion des ressources de numéros IP dans la région de service AFRINIC sont créées à travers un processus d'élaboration des politiques (PDP) qui décrit les étapes par lesquelles les propositions de politiques sont soumises, examinées, débattues (par la communauté) et adoptées (par AFRINIC). Ce document contient les politiques ratifiées et mises en œuvre qui sont passées par le PDP.

AFRINIC est une organisation indépendante à but non lucratif qui fait partie des cinq registres Internet régionaux (RIRs). Sa région de service comprend le continent africain et une partie de l'océan Indien (Seychelles, Maurice, Madagascar, Comores et Réunion).  

2.0  Définitions générales

Les termes suivants et leurs définitions sont particulièrement importants pour la compréhension des objectifs, de l'environnement et des politiques décrits dans ce document.


2.1 Registre Internet (IR)

Un registre Internet (IR) est une organisation chargée de distribuer l'espace d'adressage IP à ses clients et d'enregistrer ces adresses. Les RI sont classés selon leur fonction principale et leur portée territoriale dans la structure hiérarchique.


2.2 Registre Internet régional (RIR)

Auparavant, les registres Internet régionaux (RIR) étaient établis sous l'autorité et les initiatives des communautés Internet dans leurs régions respectives. Actuellement, l'ICANN autorise l'établissement de RIR pour servir et représenter de grandes régions géographiques. Le rôle principal des RIR consiste à gérer et distribuer l'espace d'adressage public dans leurs régions respectives.

Actuellement, il y a cinq RIRs: APNIC, ARIN, LACNIQUE, RIPE NCC et AFRINIC.


2.3 Registre Internet local (LIR)

Un registre Internet local (LIR) est un RI qui reçoit des attributions d'un RIR et qui alloue principalement l'espace d'adressage aux « utilisateurs finaux ». Les LIR sont généralement des FAI. Leurs clients sont d'autres FAI et éventuellement des utilisateurs finaux. Les LIR doivent être membres d'AFRINIC.


2.4 Attribution

« Attribuer » signifie distribuer l'espace d'adressage aux LIR pour qu’eux-mêmes les distribuent par la suite.


2.5 Sous-allocation

« Sous-attribuer » signifie distribuer l'espace d'adressage (par les LIR) aux FAI pour qu’eux-mêmes les distribuent par la suite.


2.6 Cession

Une assignation est un bloc d'adresses IP donné par un LIR à ses utilisateurs finaux pour leur propre usage. « Assigner » signifie déléguer un espace d'adressage à un FAI ou à un utilisateur final pour une utilisation spécifique dans l'infrastructure Internet qu'ils opèrent. Les assignations doivent uniquement être effectuées à des fins spécifiques documentées par des organisations spécifiques et ne peuvent être sous-attribuées à d'autres parties.


2.7 Espace IP PA (Provider Aggregatable)

L’espace d’adressage « PA » est celui qui est attribué aux LIR et qui peut être attribué ou sous-attribué par ces derniers aux utilisateurs finaux et aux réseaux en aval en tant que bloc non portable. Si l’utilisateur final / le réseau en aval change de fournisseur, l'espace d’adressage attribué ou sous-attribué par le fournisseur de service précédent (LIR) doit être restitué et le réseau modifié.


2.8 Espace IP PI (indépendant du fournisseur)

L'espace PI (ou portable) ne peut être agrégé, et ne peut être assigné que par un RIR via un LIR. L'espace PI est coûteux à acheminer et peut ne pas être globalement routable. À partir de ce type d'espace adresse, les sousattributions ne peuvent pas être effectuées par l'utilisateur final ou le LIR.

3.0  Le processus d'élaboration des politiques (PDP)

Cette section décrit le processus de développement des politiques AFRINIC (PDP). Les politiques sont des décisions documentées de la communauté AFRINIC qui déterminent directement les règles selon lesquelles AFRINIC gère et administre les ressources de numéros Internet.

Les procédures décrites ici sont conçues pour être équitables, ouvertes et objectives et visent à:

a. Offrir à toutes les parties intéressées de nombreuses possibilités de participation et de commentaires;

b. Établir un large consensus sur la communauté Internet.

Ces procédures adoptent des pratiques généralement acceptées et offrent la souplesse nécessaire pour s'adapter à diverses circonstances pouvant survenir dans un processus.


3.1  Champ d’application du PDP

Le processus d'élaboration des politiques couvre l'élaboration et la modification des politiques de gestion des ressources de numéros Internet dans la région de service AFRINIC. Les modifications apportées au processus d'élaboration des politiques lui-même suivront également le processus.

Les politiques en matière de ressources de numéros Internet se distinguent clairement des pratiques opérationnelles et des procédures générales d'AFRINIC, qui ne sont pas du ressort du PDP. 


3.2  Principes d'élaboration des politiques

Toutes les politiques sont élaborées par la communauté Internet selon les trois principes d'ouverture, de transparence et d'équité. La communauté Internet initie et examine les propositions. Si un consensus est atteint sur le projet de politique, ledit projet est recommandé au Conseil d'administration d'AFRINIC pour être adopté en tant que politique.

3.2.1 Ouverture

Toutes les politiques sont élaborées dans un forum ouvert auquel n'importe qui peut participer. La participation ne fait l’objet d’aucune condition.

3.2.2 Transparence

Tous les aspects relatifs au processus d'élaboration des politiques sont documentés et rendus accessibles au public sur le site web d'AfriNIC. Les discussions sont archivées publiquement. Toutes les procédures élaborées pour mettre en œuvre la politique sont documentées par AfriNIC et rendues accessibles au public.

3.2.3 Équité

Les politiques doivent assurer une distribution équitable des ressources et faciliter le fonctionnement d'Internet. Les mesures sont prises dans un délai raisonnable.


3.3  Groupe de travail sur l'élaboration des politiques (PDWG)

Le Groupe de travail sur l'élaboration des politiques (PDWG) discute des propositions. Ces débats sont accessibles à tous, via l’Internet ou en personne. Les travaux du PDWG se réalisent à travers la liste de diffusion des Débats sur les politiques de gestion des ressources (cette adresse e-mail qui est protégée du spam. Vous devez activer JavaScript pour la voir.

Le Groupe de travail sur l'élaboration des politiques a deux présidents pour s'acquitter de ses fonctions administratives. Lesdits présidents sont élus par la communauté d’AFRINIC lors de la réunion sur les politiques de l’Internet et servent des mandats échelonnés de deux ans. Leur mandat s’achève au cours de la première réunion sur les politiques de l’Internet, ce qui correspond à la fin du mandat pour lequel ils ont été nommés. Un mandat peut commencer ou se terminer au plus tôt le premier jour de la réunion sur les politiques de l’Internet et au plus tard le dernier jour de ladite réunion, selon ce qui est établi d’un commun accord par le président actuel et le nouveau président.

Si le président du groupe de travail n'est pas en mesure de remplir son mandat, le groupe de travail peut choisir un remplaçant pour le reste du mandat. Si les présidents des groupes de travail ne peuvent assister à la réunion sur les politiques publiques, le groupe de travail nomme un président pour la session. Toute personne présente à la réunion, en personne ou par participation à distance, peut participer au processus de sélection d'un président temporaire.


3.4  Processus d'élaboration des politiques

Tout le monde peut soumettre une proposition. Les propositions de politique sont soumises à la liste de diffusion Discussion sur la politique des ressources (cette adresse e-mail qui est protégée du spam. Vous devez activer JavaScript pour la voir.

3.4.1 Draft Proposition de politique

Au cours de l'élaboration de la politique, draft les versions du document sont mises à disposition pour examen et commentaires en les publiant sur le site Web d'AFRINIC et en les affichant sur le cette adresse e-mail qui est protégée du spam. Vous devez activer JavaScript pour la voir.

Le draft de la politique doit être disponible pour examen pendant au moins quatre semaines avant la prochaine réunion de politique publique. Le ou les auteurs doivent apporter les modifications nécessaires au draft politique en fonction des commentaires reçus. Le (s) président (s) du groupe de travail peut demander à AFRINIC de fournir une analyse (technique, financière, juridique ou autre) de l'impact de draft proposition de politique.

A draft la politique expire après une année civile à moins qu'elle ne soit approuvée par le conseil d'administration de l'AFRINIC en tant que politique. Le délai d'expiration est redémarré lorsque le draft la politique est remplacée par une version plus récente de la proposition. UNE draft la politique peut être retirée par le ou les auteurs en envoyant une notification à la liste de diffusion Resource Policy Discussion.

3.4.2 Réunion de politique publique

Le draft de la politique est inscrit à l'ordre du jour d'une réunion publique de politique publique. L'ordre du jour de la réunion doit être annoncé sur la liste de diffusion Discussion sur la politique des ressources au moins deux semaines avant la réunion. Aucune modification ne peut être apportée à un draft politique dans la semaine suivant la réunion. Ceci afin qu'une version stable du draft la politique peut être examinée lors de la réunion. Le (s) président (s) détermine (nt) si un consensus approximatif a été atteint lors de la réunion sur les politiques publiques.

Le (s) président (s) publiera le procès-verbal de la réunion de politique publique au plus tard trois semaines après la réunion.

3.4.3 Dernier appel

Un dernier examen du draft de la politique est initiée par le (s) président (s) du groupe de travail en envoyant une annonce à la liste de diffusion Discussion sur la politique des ressources. La période du dernier appel doit être d'au moins deux semaines. Le (s) président (s) du groupe de travail évaluera les commentaires reçus lors de la réunion sur les politiques publiques et pendant cette période et décidera si un consensus a été atteint.

3.4.4 Agrément

Le (s) président (s) du groupe de travail recommandera le draft politique au conseil d'administration d'AFRINIC pour approbation si elle a le consensus du groupe de travail sur l'élaboration des politiques. La recommandation comprend un rapport sur les discussions du draft politique et commentaires du dernier appel. le draft la politique sera ratifiée par le Conseil d'Administration d'AFRINIC.

3.4.5 Mise en œuvre

La date d'adoption et de mise en œuvre de la politique est annoncée sur la liste de diffusion Resource Policy Discussion. La date de mise en œuvre doit être inférieure à six mois après la fin du dernier appel, sauf si une dérogation est demandée.


3.5  Résolution de conflit

  1. Une personne qui n'est pas d'accord avec les mesures prises par le (s) président (s) doit discuter de la question avec le (s) président (s) du PDWG ou avec le PDWG. Si le désaccord ne peut être résolu de cette manière, la personne peut déposer un recours auprès d'un comité d'appel nommé par le conseil d'administration d'AFRINIC. Un appel ne peut être déposé que s'il est soutenu par trois (3) personnes du groupe de travail qui ont participé aux discussions.
  2. L'appel doit être déposé dans les deux semaines suivant la connaissance publique de la décision. Le comité d'appel remet un rapport sur son examen de la plainte au groupe de travail. Le comité d'appel peut ordonner que la décision du président soit annulée si le processus d'élaboration des politiques n'a pas été suivi.
  3. Toute personne peut demander le rappel d'un président de groupe de travail à tout moment, sur demande écrite avec justification au conseil d'administration d'AFRINIC. La demande doit être appuyée par au moins cinq (5) autres personnes du groupe de travail. Le conseil d'administration d'AFRINIC nommera un comité de rappel, à l'exclusion des personnes demandant le rappel et des présidents des groupes de travail. Le comité de rappel doit enquêter sur les circonstances de la justification du rappel et déterminer le résultat.

3.6  Variation du processus

Le processus décrit dans le présent document peut varier en cas d'urgence. Toute variation serait apportée lorsqu'une renonciation ponctuelle d'une disposition du présent Guide est requise.

  1. La décision de modifier le processus est prise par un président de groupe de travail.
  2. Il doit y avoir une explication de la raison pour laquelle la variance est nécessaire.
  3. La période d'examen, y compris le dernier appel, ne doit pas être inférieure à quatre semaines.
  4. S'il y a consensus, la politique est approuvée et doit être présentée à la prochaine réunion de politique publique.

3.7  Modèle de projet de politique

Le draft Le texte de la proposition de politique doit être soumis sur le modèle suivant:

Nom de la proposition:

ID: (attribué par AFRINIC)

Date de soumission:

Auteur:

Version:

Obsolètes:

Modifie:

1. Le problème traité par cette proposition.

2. Comment cette proposition résout le problème.

3. Proposition

  • Veuillez utiliser la sous-numérotation pour faciliter le référencement.
  • La proposition doit montrer les sections exactes à modifier et le contenu qui doit être ajouté ou supprimé du CPM.

4. Références.

5. Historique des révisions.

4.0 Hiérarchie de la distribution des ressources numériques

Les ressources de numéros Internet sont réparties dans une structure hiérarchique dans laquelle l'IANA (Internet Assigned Numbers Authority) alloue des blocs de ressources numériques à AFRINIC, qui seront redistribués dans toute la région africaine. AFRINIC redistribue à ses membres et leur délègue également le pouvoir d'effectuer des affectations et des sous-allocations aux clients le cas échéant et conformément aux politiques et procédures décrites dans ce document.

5.0 IPv4

Cette section décrit les directives pour une gestion responsable IPv4 espace d'adressage dans la région de service AFRINIC. Les lignes directrices sont élaborées dans le cadre d'un processus d'élaboration des politiques ouvert et ascendant du Groupe de travail sur l'élaboration des politiques.


5.1  Espace d'adressage IPv4

Aux fins du présent document, les adresses IPv4 sont des nombres binaires 32 bits (utilisés comme identifiants de la protocole IPv4) et sont généralement de trois types:

5.1.1 Adresses IP publiques / globales qui sont attribuées pour être globalement uniques selon les objectifs décrits dans la section 5.2 de ce document.

5.1.2 Privé IPv4 l'espace d'adressage est réservé pour une utilisation en privé IPv4 réseaux. Tout le monde peut utiliser ces adresses dans ses réseaux privés sans inscription. Hôtes avec privé IPv4 les adresses ne peuvent pas être atteintes depuis Internet à moins d'être activées via NAT (Network Address Translation). Notez que certains services Internet peuvent ne pas fonctionner correctement sous NAT. Voir RFC 2993 pour les implications techniques / d'ingénierie de l'utilisation de NAT. La RFC1918 décrit également les blocs réservés à un usage privé.

5.1.3 Plages IP réservées aux expériences:

Ils sont décrits dans la RFC3330 (http://www.ietf.org/rfc/rfc3330.txt).

Certaines plages sont également réservées à la multidiffusion.


5.2  Objectifs du système de registre Internet

5.2.1 Objectifs

Il est du devoir principal d'AFRINIC, en tant que gardien d'une ressource publique, de veiller à ce que IPv4 allocations et affectations, les objectifs suivants sont atteints:

5.2.1.1 Unicité - Afin que chaque hôte de l'Internet public puisse être identifié de manière unique, chaque monodiffusion publique IPv4 l'adresse doit être unique au monde.

5.2.1.2 Enregistrement - Chaque affectation et allocation d'espace d'adressage Internet public doit être enregistrée dans l'AFRINIC whois base de données. Cela est nécessaire pour garantir l'unicité et fournir des informations pour le dépannage Internet à tous les niveaux.

5.2.1.3 Agrégation - La distribution hiérarchique des adresses IPv4 permet l'agrégation des informations de routage. Cela permet d'assurer le bon fonctionnement du routage Internet et de limiter l'extension des tables de routage Internet (RFC2519).

5.2.1.4 Conservation - Pour maximiser la durée de vie de la ressource d'espace d'adressage Internet public, les adresses doivent être distribuées en fonction des besoins réels et sur la base d'une utilisation immédiate. Par conséquent, le stockage de l'espace d'adressage et le maintien des réservations doivent, en général, être évités.

5.2.2 Conflit d'objectifs

Les objectifs de conservation et d'agrégation sont souvent en conflit les uns avec les autres. Certains ou tous les objectifs peuvent parfois être en conflit avec les intérêts des RI individuels ou des utilisateurs finaux. Par conséquent, les RI évaluant les demandes d'allocations et d'assignations doivent analyser soigneusement toutes les considérations pertinentes et doivent chercher à équilibrer les besoins du demandeur avec les besoins de la communauté Internet dans son ensemble. Ces politiques visent à aider les RI à équilibrer équitablement ces besoins. La documentation du processus décisionnel pour chaque affectation ou mission permet de garantir la transparence et l'honnêteté du processus.

5.2.3 Documentation

Afin d'évaluer correctement les demandes, un RIR doit examiner attentivement toute la documentation pertinente relative aux réseaux en question. Cette documentation peut comprendre des plans d'ingénierie de réseau, des plans de sous-réseautage, des descriptions de la topologie de réseau et des descriptions de plans de routage de réseau. Toute la documentation doit être conforme à une norme cohérente et toutes les estimations et prévisions documentées doivent être réalistes et justifiables.

5.2.4 Équité

Toutes les politiques et pratiques relatives à l'utilisation de l'espace de diffusion publique s'appliqueront de manière juste et équitable à tous les membres actuels et potentiels d'AFRINIC, quels que soient leur emplacement, leur nationalité, leur taille ou tout autre facteur.


5.3  Exigences en matière d’enregistrement

5.3.1 Toutes les communications avec AFRINIC se feront en anglais.

5.3.2 Toutes les allocations, affectations PI, affectations PA, sous-allocations et autres types d'affectations de ressources seront enregistrées dans la base de données AFRINIC. Toutes les ressources non enregistrées seront considérées comme non valides. Les données d'enregistrement (nom, bloc / plage IP, contacts, état, etc.) doivent être correctes à tout moment. Cela est nécessaire pour prendre en charge les opérations réseau.


5.4  Atterrissage en douceur

Cette section décrit comment AFRINIC doit attribuer, allouer et gérer IPv4 ressources pendant la "phase d'épuisement" qui commence lorsque AFRINIC doit d'abord attribuer ou allouer des adresses IP à partir du bloc final / 8 de IPv4 espace d'adressage.

Afin d'assurer une transition en douceur vers IPv6, Le pool d'AFRINIC devrait être géré de manière à fournir aux membres un espace d'adressage IPv4 la piscine est épuisée. Cela aidera à maintenir IPv4 réseaux lors du déploiement IPv6 réseaux - une pratique qui caractérise la période de transition. Cette section propose une stratégie d'allocation et d'affectation et de maintenance des AFRINIC IPv4 piscine après épuisement. L'application de la politique «d'atterrissage en douceur» commence lorsque AFRINIC commence à allouer de l'espace à partir du dernier IANA alloué / 8.

Cette IPv4 La politique d'atterrissage en douceur s'applique à la gestion de l'espace d'adressage qui sera disponible pour AFRINIC après la IPv4 la piscine est épuisée. Le but de ce document est de s'assurer que l'espace d'adressage est attribué et / ou alloué d'une manière acceptable pour la communauté AFRINIC, en particulier pendant cette période de IPv4 épuisement.

5.4.1 Définitions spécifiques à la section Soft-Landing:

  1. LIR existants - Un LIR existant est un LIR qui attribue un espace d'adressage aux «utilisateurs finaux» et a déjà été attribué ou alloué IPv4 espace d'adressage par AFRINIC.
  2. Nouveau LIR - Un nouveau LIR, est un LIR qui attribue un espace d'adressage aux «utilisateurs finaux» et est membre d'AFRINIC mais n'a pas été affecté ou alloué IPv4 l'espace d'adressage avant la phase d'épuisement.
  3. Utilisateur final - Un utilisateur final est une organisation qui reçoit des attributions d'adresses IP exclusivement à utiliser dans ses réseaux opérationnels
  4. Blocs / 8 finaux de espace d'adressage IPv4 ou "Final / 8" - Le bloc Final / 8 de l'espace d'adressage IPv4 , ou "Final / 8", est le bloc / 8 de IPv4 espace d'adressage qui a été alloué par l'IANA à AFRINIC en termes de la section 2.2 C du Global Politique d'attribution du solde IPv4 Espace d'adressage au moment de l'épuisement du pool IANA de IPv4 espace d'adressage.

5.4.2 Phase actuelle.

La « Phase actuelle » est le statu quo au moment de l'adoption de la politique d'atterrissage en douceur. Au cours de cette phase, AfriNIC continue d'allouer ou d'attribuer des adresses IPv4 aux LIR et aux utilisateurs finaux en ayant recours aux directives de politique d'attribution et d'affectation déjà en place.

La phase en cours se poursuit jusqu'à ce qu'une demande d'espace adressage IPv4 autrement valide émise par un LIR ou utilisateur final à AfriNIC :

  1. ne peut aboutir à partir de l'espace d’adressage IPv4 disponible dans le pool d’adresses d’AfriNIC (à l'exception du dernier bloc /8), ou
  2. peut être satisfaite, mais viderait le pool d'adresses IPv4 d’AfriNIC (à l'exception du dernier bloc /8).

La demande qui aboutit à la satisfaction de l'une des conditions ci-dessus sera la dernière

La demande qui remplit l'une des conditions ci-dessus sera la dernière demande d'espace adresse IPv4 qu'AfriNIC acceptera de tout LIR ou utilisateur final dans la phase en cours. Si la demande peut être traitée conformément aux politiques de la phase en cours, elle sera traitée de la sorte ; sinon, elle sera traitée en fonction des politiques de la Phase d'épuisement.

AfriNIC annoncera publiquement le démarrage de la Phase d'épuisement à ce stade. Pour éviter toute ambiguïté, toutes les demandes qui sont actuellement en cours de traitement seront évaluées conformément à la nouvelle politique.

5.4.3 Phase d'épuisement

Pendant la Phase d'épuisement, les directives d'assignation et d'attribution suivantes sont appliquées. Elles s'appliquent à la fois aux LIR et aux utilisateurs finaux, ainsi qu’à tout espace d’adressage IPv4 assigné, attribué ou géré par AfriNIC pendant la transition vers la phase d'épuisement et après que celle-ci ait démarré, indépendamment du fait que cet espace adresse IPv4 fasse ou non partie du dernier bloc /8. La phase d'épuisement est divisée en deux parties :

5.4.3.1 Phase d'épuisement 1

Au cours de cette phase, l'allocation / l'attribution de l'espace d'adressage se poursuivra comme dans la phase actuelle (/ 24 pour une UE et / 22 pour une LIR) mais le maximum passera de / 10 à / 13.

Les attributions et les affectations seront faites à partir de la finale / 8 ou de tout autre IPv4 l'espace d'adressage disponible pour AFRINIC jusqu'à ce qu'un maximum de / 11 d'espace non réservé soit disponible dans la finale / 8. À ce stade, la phase d'épuisement 2 commencera. Pour éviter tout doute, toutes les demandes seront en cours à ce stade seront évaluées conformément à la nouvelle politique.

5.4.3.2 Phase d'épuisement 2

Au cours de cette phase, la taille minimale d'allocation / affectation sera / 24, et le maximum sera / 22 par allocation / affectation.

5.4.4 Pour tout LIR ou utilisateur final demandant IPv4 espace d'adressage pendant l'épuisement: 

Il n'y a pas de limite explicite au nombre de fois où une organisation peut demander l'espace d'adressage IPv4 additionnel pendant la période d'épuisement.

5.4.5 La période d'allocation et d'affectation actuelle de 12 mois sera modifiée en 8 mois.

La période d'attribution et d'affectation actuelle de 12 mois est passée à 8 mois. Cela contribuera à garantir que les LIR ne demandent que les ressources dont ils ont besoin à court et à moyen terme, et favorisera l'équité dans la répartition équitable des dernières IPv4 pool d'adresses. Cette période d'affectation restera la même pendant toute la durée de vie de la présente police.

5.4.6 Critères d'allocation

5.4.6.1 Pour recevoir IPv4 attributions ou affectations pendant la phase d'épuisement, le LIR ou l'utilisateur final doit avoir utilisé au moins 90% de toutes les allocations ou affectations précédentes (y compris celles effectuées pendant la phase en cours et la phase d'épuisement).

Dans le cas de nouveaux LIR ou utilisateurs finaux sans attributions ou affectations précédentes, cette exigence ne s'applique pas à leur première demande d'allocation ou d'attribution.

5.4.6.2 Les ressources AFRINIC sont destinées à la région de service AFRINIC et toute utilisation en dehors de la région devrait être uniquement à l'appui de la connectivité vers la région AFRINIC.

5.4.7 Réserve d'espace d'adressage IPv4

5.4.7.1 Un bloc d'adresse / 12 d'IPv4 sera en réserve avec le / 8 final.

Ce bloc d'adresse / 12 d'IPv4 sera conservé par AFRINIC pour certaines utilisations futures, encore imprévues. / 4 IPvXNUMX. Internet ne cesse d’innover et nous ne pouvons pas prédire avec certitude ce qui pourrait arriver. Par conséquent, il est prudent de mettre ce bloc en réserve, juste au cas où une exigence future créerait une demande pour des adresses IPvXNUMX.

5.4.7.2 Si le / 12 réservé reste inutilisé au moment où l'espace disponible restant a été alloué, le / 12 sera retourné au pool AFRINIC pour distribution dans les conditions de la phase 2 de la politique d'atterrissage en douceur.

5.5 IPv4 Allocations LIR / ISP

5.5.1 Politiques et directives d'allocation

5.5.1.1 Introduction

5.5.1.1.1 AFRINIC alloue des plages de IPv4 adresses aux registres Internet locaux (LIR).

Les LIR, à leur tour, réassignent ou sous-attribuent ces adresses à leurs clients. Il est aussi conseillé à tous les LIR qui assignent des adresses allouées par AFRINIC d'adopter un ensemble de politiques qui soient cohérentes avec celles décrites dans le présent document.

5.5.1.1.2 La détermination de la taille d'allocation de l'espace d'adresses IP relève de la responsabilité du personnel d'AFRINIC.

Afin de garantir que le routage inter-domaines sans classe (CIDR) est mis en œuvre et utilisé aussi efficacement que possible, AFRINIC émettra des blocs de IPv4 adresses sur les limites de bits appropriées "prises en charge par CIDR". (CIDR - "Classless Inter-Domain Routing", est expliqué dans la RFC1517-1959, https://www.ietf.org/standards/rfcs/).

5.5.1.1.3 Si un LIR envisage d'échanger ou de transférer un espace d'adressage, il doit contacter AFRINIC afin que les modifications soient correctement enregistrées.

Le LIR reste responsable de toutes les allocations enregistrées dans la base de données AFRINIC jusqu'à leur transfert vers un autre LIR ou leur restitution à AFRINIC. Les LIR doivent s'assurer que toutes les politiques sont appliquées.

5.5.1.2 Premièrement IPv4 Allocation

5.5.1.2.1 L'allocation minimale d'AFRINIC est un bloc / 22 ou 1024 d'adresses IPv4

5.5.1.2.2 L'organisation doit être un membre AFRINIC en règle et;

5.5.1.2.3 Doit montrer une utilisation efficace existante des adresses IP de leur fournisseur en amont.

La justification peut être fondée sur une combinaison de besoins immédiats et d'utilisation existante, auquel cas les assignations existantes doivent être renumérotées dans la nouvelle allocation du LIR. La vérification de l'utilisation efficace antérieure est basée sur les assignations (et sous-allocations) enregistrées dans les bases de données RIPE, ARIN, LACNIC et APNIC et seules ces assignations enregistrées seront considérées comme valides.

5.5.1.3 Mécanisme de démarrage lent pour les premières allocations

AFRINIC appliquera un mécanisme de démarrage lent à tous les nouveaux LIR. En ce qui concerne les allocations faites par AFRINIC, la première allocation reçue par un LIR sera la taille de l'allocation pratique minimale, sauf justification contraire.

La politique de démarrage lent est utilisée par tous RIRafin d'empêcher les allocations de grands blocs d'espace d'adressage qui peuvent alors rester sensiblement non attribués. AFRINIC mettra en œuvre le mécanisme de démarrage lent de manière cohérente et équitable pour chaque LIR et appliquera les mêmes principes et normes à chaque demandeur d'espace d'adressage.

5.5.1.4 Allocation supplémentaire

5.5.1.4.1 Un LIR peut recevoir une allocation supplémentaire lorsqu'environ 80% de tout l'espace d'adressage qui lui est actuellement alloué a été utilisé dans des attributions et / ou des sous-allocations valides.

Une nouvelle attribution peut également être effectuée si une seule attribution ou sous-attribution nécessite plus d'adresses que celles actuellement détenues par le LIR.

5.5.1.4.2 Les réservations ne sont pas considérées comme des assignations ou sous-attributions valides.

Il peut être utile pour l'agrégation interne de garder certains blocs IP libres pour une croissance future. Ces réservations internes ne sont toutefois pas considérées comme une utilisation valide et doivent être attribuées ou sous-allouées avant de demander une allocation supplémentaire.

5.5.1.4.3 AFRINIC essaiera toujours d'attribuer des plages d'adresses contiguës, permettant au LIR de minimiser le nombre d'annonces d'itinéraire qu'il fait.

Cependant, il ne sera pas toujours possible d'allouer une plage de valeurs contiguës à l'allocation précédente du LIR.

5.5.1.5 Sous-allocations

La taille minimale d'une sous-allocation est de / 24. Il permet à un FAI en aval d'effectuer un nombre raisonnable de petites affectations. Un LIR ne peut pas sous-allouer IPv4 espace au-dessus de sa fenêtre de sous-allocation (voir 5.5.1.13 pour les fenêtres de sous-allocation).

Les LIR peuvent effectuer des sous-allocations à plusieurs FAI en aval. (Les FAI en aval qui utilisent efficacement une sous-allocation peuvent se voir attribuer une allocation / 22 s'ils souhaitent devenir une LIR).

Le LIR est chargé de veiller à ce que l'espace d'adressage qui lui est alloué et, par la suite, l'espace d'adressage qu'il sous-alloue soit utilisé conformément aux politiques et directives de la communauté.

Il est conseillé aux LIR d'utiliser le mécanisme de démarrage lent lors de la sous-allocation aux FSI en aval. Ici, le LIR garantit que l'espace sous-alloué est utilisé efficacement et le LIR peut également surveiller et déterminer la capacité du FAI en aval à fonctionner dans le cadre des politiques définies par la communauté.

Les sous-allocations font partie de l'espace agrégeable d'un LIR. Par conséquent, un LIR devrait garantir que l'espace IP n'est pas conservé par le FAI en aval si le revendeur cesse d'obtenir la connectivité du réseau du LIR (les sous-allocations ne sont pas portables).

5.5.1.6 Politiques et directives d'attribution des AP

Les LIR doivent demander l'approbation d'AFRINIC pour toutes les sous-allocations au-dessus de leur fenêtre de sous-allocation.

Les directives suivantes sont destinées à aider les LIR et les utilisateurs finaux dans leur recherche de compromis équitables:

Documentation 5.5.1.7

Les informations requises par AFRINIC pour justifier les exigences d'adresse IP d'un utilisateur final incluent la réponse aux besoins, l'infrastructure réseau et les plans futurs. Ces informations sont requises lorsqu'un LIR demande un espace IP pour ses utilisateurs finaux au moment de l'envoi de la demande. Afin de garantir que les sous-allocations précédentes ne sont pas dupliquées, l'utilisation actuelle de l'espace d'adressage est également requise. Ces informations sont essentielles pour effectuer les approbations de sous-allocation appropriées, et le niveau de détail dépendra de la taille de la demande et de la complexité du réseau. Le LIR doit s'assurer que les informations nécessaires sont complétées avant de faire une demande de sous-allocation à AFRINIC.

Lors de la sous-allocation de leur SAW, les LIR devraient également s'assurer que ces informations sont fournies par l'utilisateur final.

5.5.1.8 Infrastructure de réseau (de LIR) vs réseaux d'utilisateurs finaux

Les adresses IP utilisées uniquement pour connecter un utilisateur final à un fournisseur de services (par exemple, des liaisons point à point) sont considérées comme faisant partie de l'infrastructure du fournisseur de services. Ces adresses ne devraient être enregistrées que dans le cadre de l'infrastructure du fournisseur de services. Lorsqu'un utilisateur final dispose d'un réseau utilisant un espace d'adressage public, cet espace doit être enregistré avec les contacts de l'utilisateur final. Si l'utilisateur final est un individu plutôt qu'une organisation, un espace peut être enregistré avec les informations de contact du fournisseur de services mais avec l'utilisateur final référencé dans l'AFRINIC whois objet de base de données.

5.5.1.9 Utilisation

L'utilisation immédiate des affectations doit représenter au moins 25% de l'espace attribué. Après un an, à moins que des circonstances particulières ne soient définies, il devrait être d'au moins 50%.

5.5.1.10 Réservations non prises en charge

Les utilisateurs finaux ne sont pas autorisés à réserver un espace d'adressage sur la base de plans à long terme. Cela viole l'objectif de conservation et fragmente l'espace d'adressage lorsque les prévisions initiales ne sont pas satisfaites. Si un LIR souhaite attribuer un espace d'adressage aux clients, il doit effectuer les affectations à partir de tout espace d'adressage non alloué ou non attribué qu'il détient actuellement. Aux fins de l'évaluation des demandes d'allocation, l'espace réservé par un LIR à d'autres clients est considéré comme inutilisé.

5.5.1.11 Validité d'une mission

Les missions restent valables tant que les critères d'origine sur lesquels la mission était basée sont toujours en place et que la mission est enregistrée dans la base de données AFRINIC. Une affectation est donc invalide si elle n'est pas enregistrée dans la base de données et si le but pour lequel elle a été enregistrée a changé ou n'est plus valable.

5.5.1.12 Renumérotation

Cela remplace les adresses IP sur une base individuelle. Les affectations valides peuvent être remplacées par le même nombre d'adresses si les critères d'attribution d'origine sont toujours remplis. Les adresses à remplacer doivent toujours être utilisées. Lorsqu'une demande de renumérotation dépasse la fenêtre de sous-allocation du LIR, la demande doit être envoyée à AFRINIC pour approbation.

Une période de trois mois est normalement considérée comme suffisante pour migrer un réseau vers le nouvel espace IP. Une fois qu'un réseau a été renuméroté, le personnel d'AFRINIC supprimera l'ancienne affectation de la base de données AFRINIC. Au cas où la période de trois mois ne serait pas suffisante, le LIR devrait informer AFRINIC du temps supplémentaire qu'il pourrait falloir pour renuméroter complètement.

5.5.1.13 Fenêtre de sous-allocation (SAW)

5.5.1.13.1 Une fenêtre de sous-allocation (SAW) fait référence au nombre maximum de IPv4 adresses que le LIR peut sous-allouer aux utilisateurs finaux sans demander l'approbation d'AFRINIC. La taille SAW est exprimée en notation CIDR.

5.5.1.13.2 AFRINIC examinera la sous-allocation faite par les LIR en utilisant leur SAW pour s'assurer que les politiques sont suivies correctement. Les LIR devraient également veiller à ce que la documentation de la sous-allocation effectuée à l'aide du SAW soit similaire à celle demandée pour les demandes plus importantes.

5.5.1.13.3 Voici quelques directives pour le SAW:

  1. Tous les nouveaux LIR ont une SAW de zéro. Toutes les sous-allocations devront être approuvées au préalable par AFRINIC.
  2. Le LIR ne peut effectuer aucune sous-allocation à l'utilisateur final au-dessus de sa SAW dans une période de 12 mois (1 an). À la fin d'une année civile à compter de l'approbation d'une SAW, la SAW est actualisée pour une année supplémentaire. Dans le cas où la SAW du LIR est épuisée pour un utilisateur final particulier, l'approbation d'AFRINIC doit être demandée pour toute autre sous-allocation au même utilisateur final.
  3. Les LIR sont invités à contacter AFRINIC pour une révision de leur SAW. Ils peuvent également demander un deuxième avis à AFRINIC même pour une sous-allocation qui pourrait être faite avec leur SAW s'ils le souhaitaient. Avant de lever une scie, les éléments suivants seront pris en considération:
    1. Toute la documentation requise est normalement présentée.
    2. Les affectations de sous-allocation précédentes de cette sous-allocation sont toutes enregistrées correctement dans la base de données.
    3. La SAW actuelle n'a pas été mal utilisée / abusée.
  4. Les nouveaux LIR sont invités à former leurs contacts pour gérer les affectations d'espace d'adressage conformément aux politiques et procédures de ce document. Si, en raison de contacts inexpérimentés au LIR, des erreurs dues à un mauvais jugement se produisent régulièrement, la SAW peut être abaissée ou supprimée pour permettre au personnel d'AFRINIC d'aider à former le personnel du LIR aux politiques de la communauté AFRINIC.

5.5.1.14 Archivage par les LIR

Les LIR doivent conserver et conserver des enregistrements de toute documentation concernant les affectations et les sous-allocations aux utilisateurs finaux. Il est nécessaire pour référence future lors de l'évaluation des demandes de la même organisation et pour tout audit par AFRINIC. Ces documents doivent être conservés électroniquement pour un accès plus facile. Il est conseillé que ces enregistrements comprennent, sans s'y limiter:

  1. La demande d'origine.
  2. Documentation à l'appui.
  3. Correspondance connexe entre le LIR et l'utilisateur final.
  4. La décision de l'affectation et les raisons de toute décision inhabituelle.
  5. Rôle de la personne qui a pris la décision.

5.6 Attribution IPv4 à l'utilisateur final (PI)

AFRINIC attribue des blocs de IPv4 des adresses aux utilisateurs finaux qui demandent un espace d'adressage pour leur usage interne dans la gestion de leurs propres réseaux, mais pas pour la sous-délégation ou la réaffectation de ces adresses en dehors de leur organisation. Les utilisateurs finaux doivent répondre à certaines exigences pour justifier l'attribution d'un bloc d'adresse.

5.6.1 Affectation minimale

En général, le bloc minimum d'espace d'adresse IP attribué par AFRINIC aux utilisateurs finaux est de / 24. Si des affectations inférieures à / 24 sont nécessaires, les utilisateurs finaux doivent contacter leur fournisseur en amont. Les préfixes attribués à l'utilisateur final proviendront d'un bloc réservé à cet effet.

5.6.2 Critères d'attribution du premier utilisateur final

Les utilisateurs finaux demandeurs doivent:

  1. Être membre AFRINIC en règle
  2. Montrez soit une utilisation efficace existante d'au moins / 25 de leur fournisseur en amont.
  3. Justifiez un besoin immédiat d'au moins 50% de la taille totale demandée en fonction de leur infrastructure réseau. Par exemple, une nouvelle entreprise.

5.6.3 Attribution de PI supplémentaire

Le taux d'utilisation de l'espace d'adressage est un facteur clé pour justifier une nouvelle attribution d'espace d'adressage IP. Les demandeurs doivent montrer exactement comment les attributions d'adresses précédentes ont été utilisées et doivent fournir les détails appropriés pour vérifier leur projection de croissance sur un an. Les critères de base à respecter sont:

  1. Un taux d'utilisation immédiat de 25%, et 
  2. Un taux d'utilisation de 50% en un an. 

Un taux d'utilisation plus élevé peut être requis en fonction des besoins individuels du réseau. Adresse IP privée: les utilisateurs finaux non actuellement connectés à un FAI et / ou prévoyant de ne pas être connectés à Internet sont encouragés à utiliser des numéros IP privés réservés aux réseaux non connectés (voir RFC 1918).

5.6.4 Affectations d'IP à l'infrastructure critique

5.6.4.1 AFRINIC affectera l'Utilisateur final aux fournisseurs d'infrastructures critiques de l'Internet tels que les points d'échange Internet publics et les fournisseurs de services DNS de base.

Ces allocations ne dépasseront pas a / 24 en utilisant IPv4. Des allocations multiples peuvent être accordées dans certaines situations. Les attributions de points d'échange DOIVENT être émises à partir de blocs spécifiques réservés uniquement à cette fin.

5.6.4.2 AFRINIC rendra publique une liste de ces blocs.

5.6.4.3 Les opérateurs de points d'échange doivent justifier l'attribution, y compris la politique de connexion, l'emplacement, les autres participants (au moins trois au total), ASNet coordonnées.

Cette politique n'empêche pas les opérateurs de points d'échange de demander un espace d'adressage en vertu d'autres politiques telles que devenir LIR.

5.6.4.4 Définitions:

5.6.4.4.1 Point d'échange:

Un point d'échange Internet est défini comme une infrastructure de réseau physique (couche 2) exploitée par une seule entité dont le but est de faciliter l'échange de trafic Internet entre les FAI. Il doit y avoir un minimum de trois FAI connectés et il doit y avoir une politique claire et ouverte pour que d'autres puissent adhérer. Les adresses nécessaires à d'autres fins (par exemple, services supplémentaires fournis aux membres) doivent être acquises par les moyens appropriés (par exemple, un FAI en amont).

5.6.4.4.2 Fournisseur de services de base DNS:

Un fournisseur de services de base DNS est une société qui fournit des services de base au niveau racine de l’arbre DNS (opérateurs de serveurs racines agréés par l’ICANN).


5.7 Transfert de ressources IPv4 dans la région AFRINIC

Comme les autres Registres Internet Régionaux, AFRINIC va bientôt épuiser sa plage d'adresses d'IPv4. Afin de répondre aux besoins des demandeurs de ressources tardifs, une politique de transfert des ressources IPv4 dans la région sont nécessaires. Le but de cette politique est de définir les conditions dans lesquelles les transferts doivent avoir lieu. La politique résout le problème d'une organisation africaine ayant besoin IPv4 nombre de ressources après l'épuisement de l'IPv4 à AFRINIC ou quand AFRINIC ne peut plus répondre aux besoins d'une telle organisation.

5.7.1 Résumé de la politique

Cette politique s'applique à une organisation ayant un besoin justifié de IPv4 ressources qui ne peuvent être satisfaites par AFRINIC.

5.7.2 Les ressources IPv4 à transférer - doit provenir d'un compte de membre AFRINIC existant ou d'un détenteur de ressources hérité dans la région de service AFRINIC.

5.7.3. Conditions relatives à la provenance du transfert

5.7.3.1 La source doit être le titulaire actuel des droits du IPv4 s'adresser aux ressources reconnues par AFRINIC, et ne pas être impliqué dans un différend quant au statut de ces ressources.

5.7.3.2 Les entités sources ne seront pas éligibles pour recevoir davantage IPv4 traiter les allocations ou les affectations d'AFRINIC pour une période de 12 mois après l'approbation du transfert.

5.7.3.3 Les entités sources ne doivent pas avoir reçu de transfert, d'allocation ou d'affectation de IPv4 nombre de ressources d'AFRINIC pour les 12 mois précédant l'approbation de la demande de transfert. Cette restriction exclut les transferts de fusions et acquisitions.

5.7.4. Conditions relatives au destinataire du transfert

5.7.4.1 AFRINIC doit approuver le besoin du destinataire pour les ressources IPv4. Pour qu’une organisation puisse prétendre à recevoir un transfert, elle doit d’abord passer par le processus de justification de besoins en ressources IPv4 auprès d'AFRINIC. C'est-à-dire que l'organisation doit justifier et démontrer auprès d'AFRINIC son utilisation initiale / supplémentaire d'allocation / affectation, le cas échéant, conformément aux politiques en vigueur.

5.7.4.2 Le destinataire doit être un membre AFRINIC, soumis aux politiques d'AFRINIC en vigueur et doit signer le contrat de services d'enregistrement pour les ressources reçues.

5.7.4.3 Les ressources héritées transférées ne seront plus considérées comme des ressources héritées. 

6.0 IPv6

La présente section définit les politiques de registre pour l'assignation et l'attribution d'adresses uniques globales IPv6 aux fournisseurs d'accès Internet (FAI) et à d’autres organisations de la région d’AfriNIC.

Elle fournit, par ailleurs, des recommandations aux registres AfriNIC, APNIC, ARIN, LACNIC et RIPE-NCC sur les politiques d'attribution des adresses IPv48 aux sites finaux. https://tools.ietf.org/html/rfc6177 .



6.1 Utilisation

Contrairement à IPv4, IPv6 est généralement attribué aux sites finaux en montants fixes. L'utilisation réelle des adresses dans chaque affectation sera faible par rapport à IPv4 missions. Dans IPv6 , l '"utilisation" n'est mesurée qu'en termes de nombre de préfixes attribués aux sites finaux, et non de leur taille ou du nombre d'adresses réellement utilisées dans ces préfixes.

6.2 Rapport HD

Le HD-Ratio est un moyen de mesurer l'efficacité de l'attribution d'adresses [RFC 3194]. Il s'agit d'une adaptation du rapport H défini à l'origine dans la [RFC1715] et s'exprime comme suit:

                 Log (nombre d’objets attribués)

HD = ------------------------------------------------ ----------

                   Log (nombre maximum d’objets attribuables)

où (dans le cas du présent document) les objets sont des adresses de sites IPv6 (préfixes /48) assignées à partir d’un préfixe IPv6 d’une certaine taille.


6.3 Objectifs de gestion de l'espace d'adressage IPv6

Les espaces adresses IPv6 sont une ressource publique qui doit être gérée avec prudence dans l’intérêt à long terme de l’Internet. Une gestion responsable des espaces adresses exige de trouver l’équilibre entre plusieurs objectifs parfois contradictoires. Les objectifs suivants sont pertinents par rapport à la politique d’adressage d’IPv6.

6.3.1 Unicité:

Chaque affectation et / ou attribution d'espace d'adressage doit garantir l'unicité dans le monde entier. Il s'agit d'une exigence absolue pour garantir que chaque hôte public sur Internet puisse être identifié de manière unique.

6.3.2 Enregistrement

L'espace d'adressage Internet doit être enregistré dans une base de données de registre accessible aux membres appropriés de la communauté Internet. Cela est nécessaire pour garantir l'unicité de chaque adresse Internet et pour fournir des informations de référence pour le dépannage Internet à tous les niveaux, allant de tous RIRs et IR aux utilisateurs finaux.

L'objectif de l'enregistrement doit être appliqué dans le contexte de considérations raisonnables de confidentialité et des lois applicables.

6.3.3 Agrégation

Dans la mesure du possible, l'espace d'adressage doit être réparti de manière hiérarchique, selon la topologie de l'infrastructure réseau. Cela est nécessaire pour permettre l'agrégation des informations de routage par les FAI et pour limiter l'expansion des tables de routage Internet.

Cet objectif est particulièrement important concernant l’adressage IPv6, car la taille de la totalité de la réserve d’adresses comporte des implications majeures tant pour le routage interne qu’externe.

Les politiques d’adressage IPv6 doivent éviter la fragmentation des plages d’adresses.

De plus, les RIR doivent appliquer des pratiques qui maximisent le potentiel d’attributions ultérieures contiguës aux attributions passées actuellement détenues. Toutefois, les attributions contiguës ne sont aucunement garanties.

6.3.4 Conservation

Bien que IPv6 fournit un pool extrêmement vaste d'espace d'adressage, les politiques d'adressage devraient éviter les pratiques inutilement inutiles. Les demandes d'espace d'adressage doivent être étayées par une documentation appropriée et le stockage des adresses inutilisées doit être évité.

6.3.5 Équité

Toutes les politiques et pratiques relatives à l'utilisation de l'espace de sonorisation doivent s'appliquer de manière juste et équitable à tous les membres existants et potentiels de la communauté Internet, quels que soient leur emplacement, leur nationalité, leur taille ou tout autre facteur.

6.3.6 Frais généraux minimisés

Il est souhaitable de minimiser la surcharge associée à l'obtention de l'espace d'adressage. Les frais généraux incluent la nécessité de revenir à RIRs pour un espace supplémentaire trop fréquemment, la surcharge associée à la gestion de l'espace d'adressage qui croît à travers un certain nombre de petites extensions incrémentielles successives plutôt qu'à travers des extensions moins nombreuses mais plus importantes.

6.3.7 Conflit d'objectifs

Les objectifs décrits ci-dessus entreront souvent en conflit les uns avec les autres ou avec les besoins des RI individuels ou des utilisateurs finaux. Tous les RI évaluant les demandes d'allocations et d'assignations doivent porter des jugements, en cherchant à équilibrer les besoins du demandeur avec les besoins de la communauté Internet dans son ensemble.

Dans la politique d’adressage IPv6, l’objectif d’agrégation est considéré comme le plus important.


6.4  Principes politiques de l’IPv6

Pour atteindre les objectifs décrits dans la section précédente, les politiques de ce document discutent et suivent les principes de base décrits ci-dessous.

6.4.1 L'espace d'adresses ne doit pas être considéré comme une propriété.

Le fait de considérer les espaces adresses comme des biens en pleine propriété va à l’encontre des objectifs du présent document et n’est pas dans l’intérêt de la communauté Internet en général.

Les politiques énoncées dans ce document reposent sur la compréhension que les espaces adresses unicast IPv6 globalement uniques sont soumises à une utilisation sous licence plutôt que vendues.

6.4.2 Routabilité non garantie

Il n’existe aucune garantie qu’une quelconque attribution ou assignation d’adresse sera routable globalement. Toutefois, les RIR doivent appliquer des procédures qui réduisent la possibilité de fragmentation d’espaces adresses, qui peuvent causer une perte de routabilité.

6.4.3 Allocation minimale

Les RIRs appliqueront une taille minimale pour IPv6 allocations pour faciliter le filtrage basé sur les préfixes. La taille d'allocation minimale pour l'espace d'adressage IPv6 est un / 32.

6.4.4 Prise en compte de IPv4 infrastructure

Lorsqu’un fournisseur de services IPv4 demande des espaces IPv6 pour une éventuelle transition de services existants vers IPv6, le nombre de clients IPv4 actuels peut être utilisé pour justifier une requête plus importante que celle-ci était fondée uniquement sur l’infrastructure IPv6.


6.5  Politiques d'allocations et d'assignations

6.5.1 Allocation initiale

6.5.1.1 Critères d'attribution initiale

Pour pouvoir bénéficier d’une attribution initiale d’espaces adresses IPv6, une organisation doit :

  1. être un LIR;
  2. présenter un plan détaillé pour fournir la connectivité IPv6/ services à d'autres organisations / utilisateurs finaux ou à des départements / entités / sites propres / apparentés dans la région AFRINIC.
  3. Montrer un plan raisonnable pour faire des assignations / 48 IPv6 sur les sites finaux dans la région AFRINIC dans un délai de douze (12) mois.
  4. L'espace d'adressage émis en vertu de cette politique doit être annoncé dans les douze (12) mois, et dans la mesure du possible, sous la forme d'un seul préfixe agrégé, afin de minimiser la croissance globale des tables de routage. Dans certains cas très particuliers, l'espace peut ne pas être annoncé, mais il doit être dûment justifié.

 6.5.1.2 Taille d'allocation initiale

  1. Les organisations qui répondent aux critères d'allocation initiaux sont éligibles pour recevoir une allocation minimum de / 32.
  2. Les organisations peuvent se qualifier pour une allocation initiale supérieure à / 32 en soumettant des documents justifiant la demande.
  3. Dans ce cas, l'allocation initiale sera basée sur l'espace nécessaire pour servir les clients de l'organisation, le nombre d'utilisateurs, l'étendue de son infrastructure, sa structure hiérarchique et / ou géographique, la segmentation de l'infrastructure pour des raisons de sécurité ou autres, et la longévité prévue pour l'allocation initiale.

6.5.1.3. Rectifier la taille des allocations initiales

Au cours du déploiement d'IPv6, si une organisation constate que la taille de l'allocation initiale qu'elle a demandée ne répond plus à ses besoins, l'organisation peut soumettre un nouveau plan d'adressage à AFRINIC, sans avoir à attendre jusqu'à ce qu'elle puisse répondre aux exigences d'une allocation ultérieure, et donc l'organisation n'aura pas à prouver les seuils d'utilisation, mais, au lieu de vouloir appliquer un plan d'adressage différent et mieux adapté à la réalité du déploiement.

La nouvelle taille sera ajustée selon le nouveau plan d'adressage comme spécifié au paragraphe 6.5.1.2., Et sera donc qualifiée pour étendre le préfixe actuel du nombre de bits nécessaire.

Dans le cas où il n'est pas possible de fournir cette longueur de préfixe car l'espace adjacent est déjà utilisé par une autre organisation, ou si effectuer l'allocation ne laisse pas suffisamment d'espace pour les allocations ultérieures, AFRINIC informera le demandeur, qui peut choisir de:

  1. Recevez un nouveau préfixe avec la nouvelle taille demandée et renumérotez leur réseau et renvoyez l'allocation initiale "originale" dans les 6 mois, ou
  2. Recevoir un préfixe complémentaire pour finaliser leur plan d'adressage, et annoncer les deux, le préfixe initial "original" et le nouveau préfixe résultant de la nouvelle allocation. À toutes fins utiles, dans le cas d'attributions ultérieures, les deux attributions doivent être considérées comme s'il s'agissait d'une attribution unique.

Chaque organisation ne peut utiliser cette procédure qu'une seule fois. Par conséquent, pour cette "deuxième opportunité", elle doit étudier attentivement les plans définitifs d'adressage du réseau à moyen et long terme.

6.5.2 Attribution ultérieure

Les organisations qui disposent d’une attribution IPv6 existante peuvent recevoir une autre attribution conformément aux politiques suivantes.

6.5.2.1 Critères d'attribution ultérieurs

Des attributions suivantes seront accordées lorsqu’une organisation (LIR) satisfait au niveau minimum d’évaluation qui consiste en l’utilisation passée d’adresses en termes de nombre de sites en unités d’assignations /48. Le ratio HD indiqué dans le document technique [RFC 3194] est utilisé pour déterminer les seuils d’utilisation qui justifient l’attribution d’adresses supplémentaires comme expliqué ci-après.

6.5.2.2 Ratio HD appliqué

La valeur HD-Ratio de 0.94 est adoptée comme indiquant une utilisation d'adresse acceptable pour justifier l'allocation d'espace d'adressage supplémentaire. La section 6.7 fournit un tableau indiquant le nombre d'assignations nécessaires pour atteindre une valeur d'utilisation acceptable pour une taille de bloc d'adresse donnée.

6.5.2.3 Taille de l'allocation ultérieure

  1. Lorsqu'une organisation a atteint une utilisation acceptable de son espace d'adressage alloué, elle est immédiatement éligible pour obtenir une allocation supplémentaire qui se traduit par un doublement de l'espace d'adressage qui lui avait été précédemment alloué. Dans la mesure du possible, l'allocation sera effectuée à partir d'un bloc d'adresse adjacent, ce qui signifie que son allocation existante sera étendue d'un bit vers la gauche.
  2. Si une organisation a besoin de plus d'espace d'adressage, l'organisation doit fournir la documentation justifiant l'espace dont elle a besoin pour servir ses clients, le nombre d'utilisateurs, l'étendue de son infrastructure, sa structure hiérarchique et / ou géographique, la segmentation de l'infrastructure pour des raisons de sécurité ou autres, et longévité prévue pour l'allocation initiale.

6.5.3 Allocation LIR-ISP

Il n'y a pas de politique spécifique pour une organisation (LIR) d'allouer de l'espace d'adressage aux FAI subordonnés. Chaque organisation LIR peut développer sa propre politique pour les FAI subordonnés afin d'encourager une utilisation optimale du bloc d'adresses total alloué au LIR. Cependant, toutes les affectations / 48 aux sites d'extrémité doivent être enregistrées soit par le LIR ou ses FAI subordonnés de telle manière que le RIR peut évaluer correctement le HD-Ratio lorsqu'une allocation ultérieure devient nécessaire.

6.5.4 Affectations

Les LIR doivent faire IPv6 missions conformément aux dispositions suivantes.

6.5.4.1 Taille de l'espace d'adressage d'affectation

Les attributions doivent être effectuées conformément au besoin spécifié par les utilisateurs des LIR ainsi qu'aux autres recommandations existantes telles que [RIPE-690 - https://www.ripe.net/publications/docs/ripe-690], highlights of which are summarized below:

  1. Les sites ou utilisateurs finaux doivent se voir attribuer un préfixe qui est un multiple de "n" / 64 qui doit être suffisant pour répondre à leurs besoins actuels et prévus, en tenant compte des protocoles existants et des possibilités futures et en évitant ainsi d'éventuels scénarios de renumérotation.
  2. La taille du préfixe à attribuer est une décision opérationnelle du LIR, bien que la sélection de / 48 soit recommandée pour une infrastructure plus simple et plus fonctionnelle pour tous les points d'extrémité du réseau.
  3. Des affectations de préfixe persistantes sont recommandées pour éviter les échecs indésirables.
  4. Il est recommandé d'utiliser un préfixe / 64 pour les liaisons point à point avec les GUA (Global Unicast Addresses).

AFRINIC ne se soucie pas de la taille de préfixe attribuée par une LIR. En conséquence, AFRINIC ne demandera pas d'informations détaillées sur IPv6 réseaux d'utilisateurs (comme dans IPv4), à l'exception des cas décrits au point 6.5.2 et aux fins de la mesure de l'utilisation.

6.5.5 Enregistrement

Lorsqu'une organisation (LIR) détenant un IPv6 l'allocation d'adresses fait IPv6 des attributions d'adresse, il doit enregistrer les informations d'affectation dans la base de données AFRINIC. Les informations sont enregistrées dans les unités des réseaux attribués / 48. Lorsque plus d'un / 48 est attribué à une organisation, l'organisation affectante est responsable de s'assurer que l'espace d'adressage est enregistré dans la base de données AFRINIC.

AFRINIC utilisera les données enregistrées pour calculer le HD-Ratio au moment de la demande d'attribution ultérieure et pour vérifier les changements dans les affectations au fil du temps.

AFRINIC doit maintenir des systèmes et des pratiques qui protègent la sécurité des informations personnelles et commerciales qui sont utilisées dans l'évaluation des demandes, mais qui ne sont pas requises pour l'enregistrement public.

6.5.6 Recherche inversée

Quand un AFRINIC délègue IPv6 l'espace d'adressage à une organisation, il délègue également la responsabilité de gérer la zone de recherche inversée qui correspond à l'allocation IPv6 espace d'adressage. Chaque organisation doit gérer correctement sa zone de recherche inversée. Lors de l'attribution d'une adresse, l'organisation doit déléguer à une organisation cessionnaire, sur demande, la responsabilité de gérer la zone de recherche inversée qui correspond à l'adresse affectée.

6.5.7 Existant IPv6 détenteurs d'espace d'adressage 

Organisations ayant reçu / 35 IPv6 allocations au titre de la précédente IPv6 politique d'adresse [RIRv6-Policies] ont immédiatement le droit de voir leur allocation étendue à un bloc d'adresse / 32, sans fournir de justification, tant qu'ils satisfont aux critères ci-dessus. Le bloc d'adresse / 32 contiendra le plus petit bloc d'adresse déjà alloué (un ou plusieurs blocs d'adresse / 35 dans de nombreux cas) qui était déjà réservé par le RIR pour une affectation ultérieure à l'organisation. Les demandes d'espace supplémentaire au-delà de la taille minimale / 32 seront évaluées comme indiqué ailleurs dans le document.


6.6  Assignations pour des essais Internet

Les organisations doivent souvent entreprendre des tests de déploiement pour de nouveaux services et technologies Internet. Elles ont besoin de ressources de numérotation pour la durée de l’essai.

L’objectif politique de conservation des ressources revêt une moindre importance lorsque des ressources sont allouées à titre temporaire.

6.6.1 Définition de l'expérience

Une organisation qui reçoit des ressources de numérotation doit documenter l’essai. Cela peut se faire sous forme de RFC expérimental de l’IETF (Voir  RFC2026, ou une «proposition d'expérimentation» détaillant les ressources nécessaires et les activités à réaliser.

La taille de l’assignation sera équivalente à la taille d’attribution minimum à la date de réception de la demande. Lorsque l’essai nécessite une variation de cette règle, celle-ci doit être indiquée dans la demande de ressources.

6.6.2 Publication

La proposition d'expérience doit être rendue publique (par exemple publiée sur le site web), lors de l'enregistrement des ressources par AFRINIC. Après la conclusion de l'expérience, les résultats doivent être publiés gratuitement et sans contraintes de divulgation.

6.6.3 Base non commerciale

Les ressources émises pour une expérience ne doivent pas être utilisées à des fins commerciales.

6.6.4 Période d'enregistrement temporaire des ressources.

Les ressources seront allouées à titre temporaire pour une période d’un an. L’enregistrement des ressources peut être renouvelé sur réception d’une nouvelle demande qui fournit des détails sur la poursuite de l’essai durant la période de prolongation.

Les ressources allouées ne peuvent être utilisées à des fins commerciales à l’issue de la période d’essai.

6.6.5 Enregistrement

AFRINIC enregistrera les ressources émises dans la base de données whois d'AFRINIC.


6.7  Rapport HD (HD) et seuil d'utilisation (T)

Le ratio HD ne se substitue pas aux mesures d’utilisation classiques actuellement effectuées par les FAI avec l’IPv4. En fait, le nombre d’objets assignés doit toujours être calculé pour l’application du ratio HD. La valeur première du ratio HD est son utilité lorsqu’il s’agit de déterminer un seuil d’utilisation raisonnable pour un espace adresse d’une taille donnée. Le présent document utilise le ratio HD pour déterminer les seuils auxquels une attribution donnée a atteint un niveau d’utilisation acceptable, justifiant ainsi l’assignation d’espaces adresses supplémentaires.

Le seuil d’utilisation T, exprimé en nombre de préfixes /48 à être attribués à partir du préfixe IPv6 P, peut être calculé ainsi :

T = 2 ((48-P) * HD)

Le seuil d’utilisation pour une organisation demandant des attributions suivantes de blocs d’adresses IPv6 est exprimé comme une fonction de la taille du préfixe et du ratio HD visé. Cette utilisation a trait aux /48 attribués à des sites finaux, pas à l’utilisation des /48 dans ces sites finaux. C’est un ratio d’attribution d’adresses et non un ratio d’utilisation d’assignations.

Conformément aux recommandations du document technique [RFC 3194], le présent document adopte un ratio HD de 0.94 comme seuil d’utilisation pour les attributions d’espaces adresses IPv6.

Le tableau suivant fournit des chiffres d'utilisation absolue et en pourcentage équivalents pour IPv6 préfixes, correspondant à un rapport HD de 0.94.

P

48-P

Total / 48s

Seuil

Util%

48

0

1

1

100.0%

47

1

2

2

95.93%

46

2

4

4

92.02%

45

3

8

7

88.27%

44

4

16

14

84.67%

43

5

32

26

81.23%

42

6

64

50

77.92%

41

7

128

96

74.74%

40

8

256

184

71.70%

39

9

512

352

68.78%

38

10

1024

676

65.98%

37

11

2048

1296

63.29%

36

12

4096

2487

60.71%

35

13

8192

4771

58.24%

34

14

16384

9153

55.86%

33

15

32768

17560

53.59%

32

16

65536

33689

51.41%

31

17

131072

64634

49.31%

30

18

262144

124002

47.30%

29

19

524288

237901

45.38%

28

20

1048576

456419

43.53%

27

21

2097152

875653

41.75%

26

22

4194304

1679965

40.05%

25

23

8388608

3223061

38.42%

24

24

16777216

6183533

36.86%

23

25

33554432

11863283

35.36%

22

26

67108864

22760044

33.92%

21

27

134217728

43665787

32.53%

20

28

268435456

83774045

31.21%

19

29

536870912

160722871

29.94%

18

30

1073741824

308351367

28.72%

17

31

2147483648

591580804

27.55%

16

32

4294967296

1134964479

26.43%

15

33

8589934592

2177461403

25.35%

14

34

17179869184

4177521189

24.32%

13

35

34359738368

8014692369

23.33%

12

36

68719476736

15376413635

22.38%

11

37

137438953472

29500083768

21.46%

10

38

274877906944

56596743751

20.59%

9

39

549755813888

108582451102

19.75%

8

40

1099511627776

208318498661

18.95%

7

41

2199023255552

399664922315

18.17%

6

42

4398046511104

766768439460

17.43%

5

43

8796093022208

1471066903609

16.72%

4

44

17592186044416

2822283395519

16.04%


6.8  Assignations PI

Cette politique vise à fournir l'espace d'adressage IPv6 aux sites finaux.

6.8.1 Introduction

Cette politique permet l'attribution des adresses IPv6 PI aux sites finaux qui détiennent et qui réunissent les fournisseurs d'infrastructures critiques tels que les serveurs racine, les domaines de premier niveau (TLD) et les points d'échange Internet publics (IXP).

6.8.2 Critères d'attribution

  1. Cible d'affectation - Organisations d'utilisateurs finaux qui fournissent des services pour le réseau de leurs organisations administratives, quelle que soit leur taille.
  2. Critères d'affectation:
    1. L'organisation ne doit pas être une LIR.
    2. L'organisation doit être ou devenir membre utilisateur final d'AFRINIC.
    3. Le site final doit justifier le besoin d'espace d'adressage IPv6 PI.
    4. Le site final doit déployer un espace d'adressage IPv6 indépendant du fournisseur sur chacun des sites d'extrémité pour lesquels des adresses sont obtenues, dans un délai de douze (12) mois.
    5. Si l'espace d'adressage émis en vertu de cette politique doit être annoncé, dans la mesure du possible, l'organisation doit regrouper toutes les annonces de préfixes afin de minimiser l'effet sur la croissance de la table de routage globale.

6.8.3 Espace d'adressage indépendant du fournisseur (PI):

  1. L'attribution indépendante du fournisseur (PI) doit être effectuée à partir d'un bloc spécifique.
  2. La taille d'attribution initiale indépendante du fournisseur pour chaque organisation doit être d'au moins a / 48 par site final. Si plusieurs sites d'extrémité sont demandés et seront connectés les uns aux autres, un préfixe aligné sur le quartet sera émis suffisamment pour autoriser au moins un / 48 par site d'extrémité. Une justification valable pour un préfixe plus court pour tous les sites d'extrémité doit être prise en compte.
  3. L'attribution de l'organisation sera calculée sur la base du nombre de sites d'extrémité et ajustée à la limite de quartet la plus proche.
  4. Les attributions suivantes doivent être documentées et justifiées. Dans la mesure du possible, ces attributions seront effectuées à partir d'un bloc d'adresses contigu (c'est-à-dire en étendant les bits "n" d'affectation existants vers la gauche).
  5. AFRINIC utilisera un algorithme d'allocation étendu lors de l'émission d'espace pour maximiser les chances de succès du mécanisme défini au paragraphe précédent.

6.8.4 Rectifier la taille d'une affectation initiale

  1. Une organisation peut soumettre un nouveau plan d'adressage à AFRINIC si le plan initialement soumis pour justifier la mission initiale ne répond plus à ses besoins actuels.
  2. La nouvelle affectation sera conforme au nouveau plan et sera conforme aux 6.8.2 et 6.8.3.
  3. Si possible, le même bloc d'adresse sera «mis à niveau» à la nouvelle taille de préfixe requise. Cependant, si les préfixes adjacents sont déjà utilisés par d'autres organisations ou si une telle affectation ne laisse pas suffisamment d'espace pour des affectations ultérieures, AFRINIC informera l'organisation requérante, qui aura les options suivantes:
    1. Recevez un nouveau bloc avec la nouvelle taille de préfixe demandée, avec l'accord d'utiliser le nouveau bloc pour tout déploiement futur et de déprécier l'ancien bloc par attrition, en le retournant lorsqu'il est vide. Il n'y a pas de date limite de retour pour le moment;
    2. Recevez un nouveau bloc qui, avec le bloc déjà attribué, couvre le nouveau besoin justifié et conservez les deux blocs.
      Cette procédure ne peut être utilisée qu'une seule fois par chaque organisation.

6.8.5 «Sous-affectations» non autorisées.

Il est autorisé d'utiliser les adresses attribuées pour:

  1. le réseau des titulaires de missions
  2. appareils tiers fonctionnant au sein de cette infrastructure
  3. interconnexions 

Il sera considéré comme une sous-affectation et, par conséquent, il n'est pas autorisé à utiliser les adresses attribuées pour fournir des services aux clients (un tel FAI), un centre de données ou des cas similaires.

7.0  ASN

Cette section contient les politiques relatives à la distribution, la gestion et l'utilisation des numéros de système autonome (AS) dans la région de service AFRINIC.


7.1  Définition

Les termes et définitions suivants sont utilisés dans ce document.

  1. Système autonome (AS) - Un système autonome (AS) est un groupe connecté d'un ou plusieurs préfixes IP gérés par un ou plusieurs opérateurs de réseau sous une politique de routage unique et clairement définie.
  2. Numéro du système autonome (ASN)
    Réseau à hébergement multiple - Un AS à hébergement multiple est un AS qui est connecté à plusieurs autres AS. Un AS est également qualifié de multi-hébergement s'il est connecté à un point d'échange Internet public.
    • Un numéro de système autonome (ASN) est un entier unique associé à un AS. le ASN est utilisé comme identifiant pour permettre à l'AS d'échanger des informations de routage dynamique avec d'autres systèmes autonomes.
    • Les protocoles de routage extérieurs (tels que le Border Gateway Protocol (BGP) décrit dans la RFC 1771) sont utilisés avec ASNs pour échanger des informations entre les réseaux. Un AS utilisera normalement un protocole de passerelle intérieure pour échanger des informations de routage sur ses réseaux internes.
    • Sur 1 Janvier 2011, RIRs a cessé de faire une distinction entre les numéros AS à 2 octets uniquement et les numéros AS à 4 octets uniquement, et gère les attributions de numéros AS à partir d'un pool d'allocation de numéros AS à 4 octets non différencié. Conformément à la RFC6793 - https://tools.ietf.org/html/rfc6793, the 4-byte pool of ASNs is 0-4294967295.
  3. Politique de routage - La politique de routage d'un AS est une description de la façon dont les préfixes de réseau sont échangés entre cet AS et d'autres systèmes autonomes.
  4. objet aut-num - Un objet aut-num est un objet dans le whois base de données utilisée pour s'inscrire ASN détails de l'affectation.

7.2  Admissibilité à l'attribution d'un numéro AS

Il est important de déterminer quels sites nécessitent des numéros AS uniques. Les sites qui ne nécessitent pas de numéro AS unique doivent utiliser un ou plusieurs des numéros AS réservés à un usage privé (RFC1930, RFC6996).

Pour pouvoir prétendre à un numéro AS, l'organisation demandeuse doit être membre de la ressource AFRINIC et remplir l'une des conditions suivantes:

7.2.1 Interconnexion (y compris l'homologation) avec plus d'un AS.

7.2.2 Afficher une politique de routage unique ou démontrer un besoin technique pour une coordination mondiale unique ASN.

Une organisation sera également éligible si elle peut démontrer qu'elle répondra aux critères ci-dessus lorsqu'elle recevra un ASN (ou dans les six mois suivants).


7.3  Considérations relatives à la propriété et au routage

Propriété 7.3.1

La communauté Internet considère ASNs en tant que ressource publique qui ne devrait être distribuée qu'en fonction des besoins démontrés. Ni la cession ni l'enregistrement ne confèrent la propriété des ressources. Les organisations qui utilisent ASNs sont considérés comme des «gardiens» plutôt que des «propriétaires» de la ressource et n'ont pas le droit de vendre ou autrement transférer cette ressource à d'autres parties.

7.3.2 Considérations de routage

Gestion responsable de ASNs est nécessaire pour limiter l'expansion des tables de routage globales. L'agrégation de préfixes d'adresses IP contigus au sein de systèmes autonomes uniques permet de minimiser le nombre de routes annoncées vers Internet mondial.


7.4  Procédures d'assignation

AFRINIC assigne des numéros AS pour les systèmes autonomes situés dans la région de service AFRINIC et accepte les demandes des LIR, des non-LIR et des non-membres remplissant les conditions d'éligibilité de la section 7.2 du présent document.

AFRINIC peut demander de telles informations qui peuvent aider à comprendre la politique de routage prévue et à décider si un numéro AS est réellement nécessaire.

7.4.1 Utilisation ASNs pour le réseau LIR

Attribution aux FAI qui utiliseront le ASN dans leur propre réseau sont soumis aux conditions suivantes:

  1. Le FAI demandeur est responsable du maintien de l'enregistrement décrit à la section 7.7.
  2. Le FAI demandeur a le droit de continuer à utiliser le ASN, même s'ils changent d'homologues du réseau ou de fournisseurs de services.

Les LIR avec AFRINIC ne seront pas facturés de frais de maintenance annuels pour ASNs.

7.4.2 Fournir ASNs aux non-LIR

Les attributions à d'autres organisations qui ne sont pas des LIR sont soumises aux conditions suivantes:

  1. L'entreprise qui utilisera réellement le ASN doit répondre aux critères ci-dessus.
  2. L'entreprise requérante est responsable du maintien de l'enregistrement décrit ci-dessous.
  3. Des frais d'inscription uniques seront facturés pour chaque ASN attribué, comme décrit dans le barème des frais d'AFRINIC. Tous les trois ans par la suite, AFRINIC facturera à l'organisation des frais de maintenance annuels, payables à la date anniversaire de la mission d'origine.

7.5  Exigences en matière d’enregistrement

Tous ASNLes attribués doivent être enregistrés publiquement dans l'AFRINIC whois base de données. AFRINIC créera l'objet 'aut-num' dans la base de données.

Tous les attributs de l'objet 'aut-num' doivent être correctement enregistrés conformément à l'AFRINIC whois documentation de la base de données.

7.5.1 Enregistrement des personnes de contact

Les interlocuteurs administratifs et techniques doivent être enregistrés pour chaque ASN attribué. Le contact administratif enregistré («admin-c») est la personne responsable de la ASN et devrait généralement être quelqu'un qui est physiquement situé sur le site de l'AS.

Le contact technique («tech-c») ne doit pas nécessairement être physiquement situé sur le site de l'AS, mais doit être une personne responsable du fonctionnement quotidien de cet AS.

7.5.2 Enregistrement de la politique de routage

AFRINIC recommande que la politique de routage de l'AS soit enregistrée dans whois Base de données chacun ASN attribué.

7.5.3 Mise à jour des données d'enregistrement

LIR est responsable de ASNs doivent mettre à jour l'objet 'aut-num' dans AFRINIC whois base de données si l'une des informations d'enregistrement change.


7.6  Restitution d’ASN non utilisés

Si une ASN n'est pas utilisé par l'organisation qui l'a reçu à l'origine, il doit être retourné. AFRINIC le remettra ensuite dans le pool public de numéros AS pour une réaffectation à un autre système autonome dans la région AFRINIC.


7.7  Disposition générale

AFRINIC peut publier d'autres directives concernant ASNs y compris les détails de facturation (frais de récupération de la maintenance) et les accords connexes, les formulaires de demande, une description plus détaillée des procédures d'évaluation, des pratiques que le LIR demande ASNs devraient adopter et des informations susceptibles d'aider les organisations à demander ASNs.

Toute autre directive publiée sera élaborée au sein de la communauté (si nécessaire) et sera conforme aux objectifs et politiques décrits dans ce document.

8.0  Coordonnées de contact spécifiques aux cas d’abus

8.1  Introduction

Cette politique spécifie un objet dédié qui doit être utilisé comme lieu préféré pour publier des informations de contact public abusives dans la région de service AFRINIC.

L'objet mentionné peut être référencé dans les objets inetnum, inet6num et aut-num dans l'AFRINIC whois base de données. Il fournit un moyen plus précis et efficace pour les rapports d'abus d'atteindre le bon contact réseau.


8.2  La politique en détail:

Pour rendre disponible un nouveau ou utiliser un déjà existant whois objet de base de données qui implémente les propriétés suivantes:

  1. Une référence unique par inetnum, inet6num et aut-num
  2. Contient 2 attributs de messagerie:
    1. "e-mail:" pour la communication personnelle
    2. "abuse-mailbox:" pour la gestion automatique des rapports

L'objet doit être accessible via le whois protocole. AFRINIC pour publier un Document de bonnes pratiques qui encourage tous les membres à utiliser activement l'objet pour publier des informations de contact en cas d'abus.


8.3  Avantages et inconvénients de la politique

8.3.1 Avantages

  1. Les réseaux pourront fournir leurs propres coordonnées directes aux services d'abus.
  2. Les plaintes pour abus ne seront plus envoyées au "mauvais" contact.
  3. Cela permet une plus grande flexibilité administrative et opérationnelle, et un traitement plus rapide des abus sera possible.

8.3.2 Inconvénients

Cet objet, comme tous les autres objets existants, sera confronté au problème de précision des données. Cette politique vise à résoudre le problème d'une place manquante pour les coordonnées d'abus et n'améliorera pas l'exactitude des données dans le whois base de données. Néanmoins, il est suggéré à AFRINIC de proposer un moyen de recevoir des rapports sur des objets non fonctionnels ou non précis.

 

9.0  Allocations et assignations de ressources temporaires

Dans certaines circonstances, les organisations peuvent avoir besoin de ressources IP pendant une certaine période, généralement un mois et moins. Cela pourrait être pour des expositions, des conférences, des conventions, etc.

AFRINIC attribuera donc des ressources de numérotation aux entités nécessitant des numéros IP temporaires pour une durée déterminée. Dans ce document, «ressources IP» fait référence à la monodiffusion IPv4Adresses / v6 et numéros AS.


9.1  Documenter l'activité temporaire

L'activité nécessitant des ressources IP temporaires doit être documentée publiquement et disponible, de préférence sur un site Web. Les entités nécessitant de telles ressources IP doivent démontrer qu'elles comprennent que lorsque l'activité ou l'expérience pour laquelle elles ont besoin des ressources IP prend fin, les ressources IP seront retournées à AFRINIC.

Un «document accessible au public» est un document qui est publiquement et ouvertement accessible gratuitement et sans aucune contrainte de divulgation.

AFRINIC ne reconnaîtra aucune activité dans le cadre de cette politique si une telle activité ne peut être rendue publique.


9.2  Affectations de ressources IP

Les ressources sont attribuées sur une base de location pour une période d'un mois. La mission peut être renouvelée sur demande auprès d'AFRINIC en fournissant les informations nécessaires. La taille de la ressource IP attribuée sera déterminée à partir du plan soumis par l'entité requérante.

9.2.1 Documentation requise:

L'organisme demandeur doit contacter AFRINIC avec les informations suivantes:

  1. Détails de l'organisation: nom de l'organisation légale, pays d'enregistrement, adresse postale, adresse physique, numéros de téléphone et de fax, site Web (c'est un must).
  2. Détails de l'activité nécessitant une affectation temporaire: site Web détaillant l'activité ou site Web avec un lien vers des activités précédentes similaires, liens à partir d'autres sites (pertinents) sur cette activité, et date à laquelle l'activité ci-dessus se termine.
  3. Utilisation prévue de ces ressources IP: indiquez la taille de sous-réseau requise et son utilisation, ainsi que les numéros AS et inversez la délégation si nécessaire.
  4. La date de retour prévue des ressources IP ci-dessus.

9.3  Taxes administratives

AFRINIC peut facturer des frais administratifs (si nécessaire) pour l'attribution des numéros IP temporaires ci-dessus.

10.0  Délégation inverse

Cette section décrit la politique de délégation inverse des assignations et attributions IPv4 et IPv6 dans la région desservie par AfriNIC. Veuillez noter que les registres AfriNIC ne font qu'inverser les délégations et ne sont pas impliqués dans le système d'enregistrement des noms de domaine.


10.1  Introduction

AfriNIC fournit un support pour permettre aux applications de correspondre à un nom de domaine à partir d'une adresse IP. La délégation inverse est obtenue en utilisant les domaines in-addr.arpa (IPv4) et ip6.arpa (IPv6).


10.2  Obtention de la délégation d'une sous-zone in-addr.arpa

AfriNIC n'accepte que les demandes de délégation inverse dans le cadre d'in-addr.arpa émanant de ses LIR actifs. Les utilisateurs finaux doivent envoyer leurs demandes au LIR auprès duquel ils ont obtenu les adresses ou, dans le cas des adresses indépendantes du fournisseur, à l'un des LIR de leur choix. AfriNIC effectuera des tests pour s'assurer que le serveur de noms de la zone sur laquelle la délégation inverse est demandée soit installé et configuré conformément aux recommandations issues du document technique RFC1912.


10.3  Délégation inverse pour l'espace d'adressage lié au fournisseur d’accès (PA)

AfriNIC ne fera que des délégations sur des frontières de 8 bits (/16 ou /24). Des délégations multiples peuvent être appelées à couvrir les préfixes CIDR de longueur supérieure à /24.


10.4  Délégation inverse pour l'espace d'adressage indépendant du fournisseur (PI)

AFRINIC inversera la délégation d'une zone dans in-addr.arpa à un utilisateur final auquel un espace PI a été attribué.

Pour les délégations de blocs d'adresses inférieurs à a / 24, la méthode décrite dans «Délégation IN-ADDR.ARPA sans classe» [RFC 2317] sera utilisée.


10.5  Validité de la délégation inverse

10.5.1 AFRINIC accepte les demandes de délégation et les modifications des délégations des LIR dont le statut de membre est à jour.

10.5.2 Aucun service DNS inversé en l'absence d'affectations enregistrées:

  1. Aucune délégation inverse de l'espace d'adressage IP administré / alloué n'est autorisée à moins qu'une attribution ou une sous-allocation de l'allocation d'adresse spécifique ne soit enregistrée de manière appropriée dans l'AFRINIC whois base de données. 
  2. Pour une délégation inversée / 24, au moins une affectation ou sous-allocation doit être enregistrée dans la base de données AFRINIC pour ce / 24 spécifique. Il n'est pas nécessaire d'attribuer l'intégralité du / 24 pour que la délégation inverse soit autorisée.

10.6 Délégation inverse IPv6

Le consensus de l'IETF a été atteint sur le fait que le domaine ip6.arpa est utilisé pour une correspondance adresse / nom DNS pour le IPv6 espace d'adressage. Faire référence à RFC2874 et RFC3596.

La délégation du domaine ip6.arpa est effectuée par Internet Assigned Numbers Authority (IANA). Les noms dans cette zone sont délégués aux registres Internet régionaux conformément à leur délégation respective de IPv6 espace d'adressage.


10.7 Suppression des délégations «Lame»

Une fois qu'un attribut «nserver» donné a été déterminé comme étant boiteux pour un domaine donné, et que des tentatives raisonnables ont été faites pour contacter la ou les personnes responsables, l'attribut nserver doit ensuite être supprimé de l'objet de domaine donné. Une ligne «remarques» doit être ajoutée à l'objet de domaine dans la base de données enregistrant cela.

Dans le cas où tous les enregistrements de serveur de noms sont boiteux pour une délégation donnée, l'objet de domaine serait supprimé dans son intégralité. Les informations historiques sur les objets de domaine supprimés doivent être archivées pendant une durée raisonnable et mises à disposition si nécessaire.

11.0  Réservations de ressources pour les points d'échange Internet

Cette politique demande à AFRINIC de réserver et de publier IPv4 les ressources, et ASNs à l'usage des IXP uniquement. 


11.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. 

N'ayant pas d'adresses IPv4 à développer, les nouveaux IXP créeraient une complexité de routage inutile pour les réseaux connectés à Internet, cherchant à procéder à des échanges de trafic sur d’autres IXP pour étendre leur portée réseau.

AFRINIC dispose déjà d'une politique existante pour effectuer des allocations aux IXP [1], mais cette politique ne réserve pas spécifiquement d'espace IPV4 pour garantir qu'il y en aura, pour que les futurs IXP puissent croître et se développer. 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. 


11.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 du réseau, il est donc souhaitable que l'espace « peering LAN » 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 tels que la surveillance, les statistiques, la messagerie, les systèmes de tickets, le transport vers les serveurs racine du DNS, etc. Les réseaux de gestion sont conçus pour être accessibles partout dans le monde, par exemple pour publier des données et permettre l'accès à distance à une infrastructure de réseau commune (comme les serveurs DNS racine et TLD) et aux projets de recherche. 


11.3 Utilisation des serveurs de route BGP

En règle générale, les IXP utilisent des serveurs de routage BGP pour aider à gérer les sessions d'appairage entre différents participants. Les serveurs de route implémentent 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 route BGP IXP 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 ASN de 4 octets utilisé sur son serveur de routage ne serait pas en mesure d'implémenter avec succès le mappage de routage A: B BGP, si un participant IXP a un ASN de 4 octets. Un plus grand nombre d'IXP risquent de connaître cette situation, car des ASN supplémentaires de 4 octets 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. 


11.4 Détail de la politique

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 assignations pour les LAN d’échange IXP doivent provenir d'un bloc dédié, publié en tant que tel par AfriNIC. Les LAN d’échange attribués à chaque IXP doivent garantir que le bloc IP adjacent de préfixe /24 soit réservé (sur la base de la taille minimale d'attribution de /24 aux utilisateurs finaux en vertu de la politique) pour prendre en charge la croissance future de l'IXP. Cela permettra à un IXP d'augmenter à /23 ses ressources LAN d’échange sans avoir à renuméroter une nouvelle attribution de bloc contigu d’adresses IP. 

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é à AfriNIC de réserver un bloc d’adresses /16 pour les besoins futurs des LAN d’échange IXP dans la région qu’il dessert et de publier ce bloc en tant que tel. De plus, les assignations pour le LAN d’échange IXP devraient réserver le bloc /24 contigu au point IXP demandeur pour en assurer la 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 grand 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. 


11.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. 

 

12.0  Assignation de ressources Anycast

Cette politique permet à une organisation de recevoir une assignation ou une attribution IPv4 / IPv6 et un numéro AS uniquement pour une utilisation anycast ou GXS (RoX Exchange).


12.1 Résumé

Cette politique permet l'utilisation de:

  1. Un bloc /1 IPv24 pour les services anycast à partir d'une attribution PA obtenue d'un LIR ou d'un utilisateur final direct.
  2. Un bloc /48 d'IPv6 pour les services anycast à partir d'une attribution IPv6 obtenue d'un LIR ou d'un utilisateur final direct.
  3. Un numéro AS pour une utilisation anycast.

Le personnel d'AfriNIC considèrera les blocs IPv4 / IPv6 anycast assignés comme étant « pleinement utilisés » par le LIR lorsqu’il envisagera une première attribution ou une attribution supplémentaire à un LIR.


12.2 Énoncé de politique

12.2.1 Une organisation peut obtenir un (1) / 24 IPv4 et / ou un (1) / 48 IPv6 préfixe à des fins de diffusion ou GRX à partir d'une attribution ou d'une attribution directe d'utilisateur final émise par AFRINIC.

Un numéro AS doit également être délivré aux mêmes fins sur demande. Ces ressources doivent être utilisées dans le seul but de fournir des services anycast. Celles-ci IPv4/IPv6 les préfixes compteront comme étant pleinement utilisés lorsqu'une organisation demande des ressources supplémentaires. Les critères d'utilisation qui s'appliquent à tous IPv4 et IPv6 les demandes d'attribution ou d'attribution initiales seront supprimées pour les demandes d'assignation à diffusion multiple.

12.2.2 Les blocs utilisés pour les services anycast ne peuvent pas être attribués ou sous-attribués.

Ils doivent être classés « ASSIGNED ANYCAST » dans la base de données Whois d’AfriNIC.

 

Print Friendly, PDF & Email
Dernière modification le -