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

Le guide collectif des politiques (v1.2)

Print Friendly, PDF & Email

Cette version CPM est remplacée par cette version CPM

 

 
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: APNICARIN, LACNICRIPE 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 PA est ce qui a été alloué aux LIR à partir duquel ils peuvent attribuer ou sous-allouer aux utilisateurs finaux / réseaux en aval en tant que bloc non portable. Si l'utilisateur final / le réseau en aval change de fournisseur, l'espace adresse attribué ou sous-alloué par le fournisseur de services précédent (LIR) doit être renvoyé et le réseau renuméroté.


2.8 Espace IP PI (indépendant du fournisseur)

L'espace PI (ou portable) ne peut pas être agrégé et ne peut être attribué que par RIR via un LIR. L'espace PI est coûteux à acheminer et peut ne pas être routable à l'échelle mondiale. Les sous-allocations ne peuvent pas être effectuées à partir de ce type d'espace d'adressage 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. Tout le monde peut participer via Internet ou en personne. Le travail du PDWG s'effectue via la liste de diffusion Discussion sur la politique des ressources (Cette adresse e-mail est protégée du spam. Vous devez activer Javascript pour la voir.) et au cours des réunions semestrielles d'AFRINIC sur les politiques de l’Internet (PPM). Tout individu y participant en personne ou à distance est considéré comme faisant partie du Groupe de travail sur l'élaboration des politiques.

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 est protégée du spam. Vous devez activer Javascript pour la voir.) par l'auteur. AFRINIC fournira un service d'assistance administratif et assistera le ou les auteurs dans draftla proposition, si demandé. AFRINIC fournira également des faits et des statistiques pertinents si nécessaire au cours de la discussion.

3.4.1 Draft Proposition de politique

Lors de l'élaboration d'une 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 est protégée du spam. Vous devez activer Javascript pour la voir. liste de diffusion. Chaque draft La politique se voit attribuer un identifiant unique par AFRINIC et le site Internet d'AFRINIC doit également contenir l'historique des versions et le statut de toutes les propositions.

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 de la draft 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 au cours de 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: (laisser en blanc Ð AFRINIC attribué)

Date de soumission:

Auteurs):

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 (https://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 pour fournir des informations pour le dépannage Internet à tous les niveaux.

5.2.1.3 Agrégation - Distribuer Ipv4 les adresses de manière hiérarchique permet l'agrégation des informations de routage. Cela permet de garantir le bon fonctionnement du routage Internet et de limiter l'expansion 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 Global Policy for the Allocation of the Remaining IPv4 Address Space  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 actuelle se poursuivra jusqu'à ce qu'une demande de validité IPv4 l'espace d'adressage de n'importe quel LIR ou utilisateur final à AFRINIC soit:

  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 que la phase d'épuisement a commencé à ce stade. Pour éviter tout doute, toutes les demandes qui sont actuellement en cours à ce stade seront évaluées conformément à la nouvelle politique.

5.4.3 Phase d'épuisement

Pendant la phase d'épuisement, les directives d'allocation et d'affectation suivantes seront utilisées. Ils s'appliquent aux LIR et aux utilisateurs finaux, ainsi qu'à tous les IPv4 l'espace d'adressage alloué, attribué ou autrement géré par AFRINIC pendant la transition vers et après le début de la phase d'épuisement, indépendamment du fait IPv4 l'espace d'adressage fait partie de la finale / 8. La phase d'épuisement sera 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 qui 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 sur le nombre de fois qu'une organisation peut demander des IPv4 l'espace d'adressage 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'allocation et d'affectation actuelle de 12 mois sera modifiée en 8 mois. Cela contribuera à garantir que les RIL ne demandent que les ressources dont ils ont besoin à court et moyen terme et à promouvoir 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 allocations 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 A / 12 IPv4 bloc d'adresse sera en réserve sur la finale / 8. This / 12 IPv4 le bloc d'adresse sera conservé par AFRINIC pour certaines utilisations futures, encore imprévues. Internet est innovant et nous ne pouvons pas prédire avec certitude ce qui pourrait arriver. Par conséquent, il est prudent de garder ce bloc en réserve, au cas où une exigence future créerait une demande de IPv4 Adresses.

5.4.7.2 Lorsque AFRINIC ne peut plus répondre aux demandes d'espace d'adressage (du Final / 8 ou de tout autre espace d'adressage disponible), le Conseil peut, à sa discrétion et compte tenu de la demande et d'autres facteurs au moment, reconstituer l'épuisement pool avec n'importe quel espace d'adressage (ou une partie de celui-ci) qui peut être disponible pour AFRINIC à ce moment, d'une manière qui est dans le meilleur intérêt de la communauté.


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 réaffectent ou sous-allouent cet espace à leurs clients. Il est également conseillé à tous les espaces d'adressage LIR alloués par AFRINIC d'adopter un ensemble de politiques cohérentes avec les politiques décrites dans ce 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. Dans un effort pour s'assurer 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/rfc.htm).

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'à ce qu'elles aient été transférées vers un autre LIR ou renvoyées à 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 cependant pas comptabilisé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'allouer 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 contiguë à 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, l'espace peut être enregistré avec les coordonnées du prestataire 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 utilisant leur SAW pour s'assurer que les politiques sont correctement suivies. Les LIR devraient également veiller à ce que la documentation pour 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 lignes directrices 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, le SAW peut être réduit ou supprimé pour permettre au personnel d'AFRINIC d'aider à former le personnel du LIR aux politiques de la communauté AFRINIC.

5.5.1.14 Tenue de registres 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. Décision de la mission et motifs 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 un / 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 fournir une justification de l'attribution, notamment: la politique de connexion, l'emplacement, les autres participants (au minimum 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 DNS de base est une entreprise qui fournit des services DNS pour le niveau racine de l'arborescence DNS (opérateurs racine sanctionné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 IPv4 les ressources à transférer doivent 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 légitime actuel des adresses IPv4 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 d'autres allocations ou assignation d'IPv4 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çus de transfert, d'allocation ou d'assignation de ressources IPv4 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 que le bénéficiaire a besoin de ces adresses 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 avec AFRINIC. C'est-à-dire que l'organisation doit justifier et démontrer avec AFRINIC son utilisation initiale / allocation additionnelle / assignation, le cas échéant, conformément aux politiques en vigueur.

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

5.7.4.3 Les ressources IPv4 legacy transférées ne seront plus considérées comme des ressources legacy. 

6.0 IPv6

Cette section définit les politiques de registre pour l'attribution et l'allocation de ressources uniques au monde IPv6 des adresses aux fournisseurs d'accès Internet (FAI) et à d'autres organisations de la région AFRINIC. Il fournit des recommandations aux registres d'adressage (AFRINIC, APNIC, ARIN, LACNIC et RIPE-NCC) sur les politiques d'attribution IPv6 adresse des blocs aux sites d'extrémité.

En particulier, il recommande l'attribution de / 48 dans le cas général, / 64 lorsqu'il est connu qu'un et un seul sous-réseau est nécessaire et / 128 lorsqu'il est absolument connu qu'un et un seul périphérique se connecte. Pour plus de détails sur ce document, veuillez lire le RFC-3177


6.1 Utilisation

contrairement à IPv4, IPv6 est généralement attribué aux sites finaux en montants fixes (par exemple / 48). 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 bits à gauche de la limite / 48. En d'autres termes, «utilisation» fait référence à l'attribution de / 48 à des sites finaux et non au nombre d'adresses attribuées au sein de / 48 individuels à ces sites finaux.

Tout au long de ce document, le terme «utilisation» fait référence à l'allocation de / 48 aux sites finaux et non au nombre d'adresses attribuées au sein des / 48 individuels au sein de ces sites finaux.


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

IPv6 l'espace d'adressage est une ressource publique qui doit être gérée avec prudence au regard des intérêts à long terme d'Internet. La gestion responsable de l'espace d'adressage implique d'équilibrer un ensemble d'objectifs parfois concurrents. Les objectifs suivants sont pertinents pour IPv6 adresse politique.

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 existant IPv4 demandes des fournisseurs de services IPv6 espace pour la transition éventuelle des services existants vers IPv6, le nombre de IPv4 les clients peuvent être utilisés pour justifier une demande plus importante que celle qui serait justifiée si elle IPv6 Infrastructure.


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. Ne pas être un site final;
  3. Afficher un plan détaillé à fournir IPv6 connectivité avec les organisations de la région AFRINIC.
  4. présenter un plan raisonnable pour offrir des assignations /48 d'IPv6 aux sites finaux de la région d’AFRINIC dans un délai de douze mois

6.5.1.2 Taille d'allocation initiale

Les organisations qui répondent aux critères d'allocation initiaux sont éligibles pour recevoir une allocation minimum de / 32.

Les organisations peuvent se qualifier pour une allocation initiale supérieure à / 32 en soumettant une documentation qui justifie raisonnablement la demande. Dans l'affirmative, la taille de l'allocation sera basée sur le nombre d'utilisateurs existants et l'étendue de l'infrastructure de l'organisation.

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

Lorsqu'une organisation a atteint une utilisation acceptable pour 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 est 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 est étendue d'un bit vers la gauche.

Si une organisation a besoin de plus d'espace d'adressage, elle doit fournir une documentation justifiant ses besoins pour une période de deux ans. L'allocation effectuée sera basée sur cette exigence.

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 affectations doivent être effectuées selon les directives suivantes:

  1. / 48 dans le cas général, sauf pour les très gros abonnés.
  2. / 64 lorsqu'il est connu qu'un et un seul sous-réseau est nécessaire par conception
  3. / 128 lorsqu'il est absolument connu qu'un et un seul appareil se connecte.

AFRINIC ne se soucie pas de la taille d'adresse qu'un LIR attribue réellement. En conséquence, AFRINIC ne demandera pas les informations détaillées sur IPv6 réseaux d'utilisateurs (comme dans IPv4), à l'exception des cas décrits au point 6.3.3 et dans le but de mesurer l'utilisation telle que définie dans le présent document.

6.5.4.2 Affectation de plusieurs / 48s à un seul site final

Lorsqu'un site final unique nécessite un bloc d'adresse supplémentaire / 48, il doit demander l'affectation avec la documentation ou les documents qui justifient la demande. Les demandes de multiple ou de 48 supplémentaires seront traitées et examinées (c.-à-d., Évaluation de la justification) au RIR niveau.

Remarque: Il n'y a aucune expérience à l'heure actuelle avec l'affectation de plusieurs / 48 au même site d'extrémité. La révision par AFRINIC de toutes ces missions est censée être une mesure temporaire jusqu'à ce qu'une certaine expérience ait été acquise et que des politiques communes puissent être développées. En outre, des travaux supplémentaires pour définir les politiques dans cet espace seront probablement menés dans un avenir proche.

6.5.4.3 Affectation à l'infrastructure de l'opérateur

Une organisation (LIR) peut attribuer un / 48 par PoP comme infrastructure de service d'un opérateur de service IPv6 . Chaque assignation à un PoP est considérée comme une assignation quel que soit le nombre d'utilisateurs utilisant le PoP. Une assignation distincte peut être obtenue pour les opérations internes de l'opérateur.

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 l'AFRINIC whois Base de données.


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

La politique actuelle ne permet pas IPv6 attribution d'une adresse indépendante du fournisseur (PI) à tout «site d'extrémité». De plus, le manque de IPv6 le transport obligera de nombreux «sites d'extrémité» à creuser un tunnel. Ainsi, pour éviter de renuméroter lorsque IPv6 le transport sera disponible, une affectation indépendante du fournisseur semble raisonnable. Plus encore, tous les LIR n'ont pas IPv6 allocations d'espace d'adressage. Cela rend impossible pour les utilisateurs finaux d'obtenir PA IPv6 l'espace d'adressage d'un tel amont (LIR). Cette politique vise également à fournir IPv6 adresser de l'espace à ces utilisateurs finaux tant qu'ils ont déjà ou se qualifient pour obtenir un PI IPv4 Adresses.

6.8.1 Introduction

Cette politique permet d'attribuer des «sites finaux» IPv6 adresses indépendantes du fournisseur (PI).

Les «sites finaux» incluent les utilisateurs finaux qui ont déjà ou sont qualifiés pour obtenir IPv4 Adresses PI et fournisseurs d'infrastructures critiques tels que les opérateurs de serveurs racine TLD et les points d'échange Internet publics (IXP).

6.8.2 Critères d'attribution

  1. Cible d'affectation - Sites finaux qui fournissent des services Internet publics pour un seul réseau d'organisations administratives, quelle que soit leur taille.
  2. Critères d'affectation:
    1. Le site final ne doit pas être un IPv6 LIR
    2. Le site final doit devenir un membre utilisateur final AFRINIC et payer les frais AFRINIC normaux pour sa catégorie d'adhésion.
    3. Le site final doit soit être titulaire de IPv4 Espace d'adressage PI ou éligible pour un IPv4 Affectation PI d'AFRINIC dans le cadre du IPv4 actuellement en vigueur.
    4. Le site final doit justifier la nécessité de la IPv6 Espace d'adressage PI.
    5. Le «site final» doit montrer un plan d'utilisation et annoncer le IPv6 espace d'adressage indépendant du fournisseur dans les douze (12) mois. Passé ce délai, s'il n'est pas annoncé, le IPv6 L'espace d'adressage PI doit être récupéré et renvoyé au pool gratuit par AFRINIC.

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

  1. L'affectation indépendante du fournisseur (PI) doit être effectuée à partir d'un bloc spécifique.
  2. La taille d'affectation indépendante du fournisseur initial à un site d'extrémité doit être de / 48, ou un préfixe plus court si le site d'extrémité peut le justifier.
7.0  ASN

Cette section contient des politiques et des directives concernant la demande, l'attribution et l'enregistrement de numéros AS (Autonomous System) dans la région AFRINIC.


7.1  Introduction

AFRINIC (l'African Network Information Center) est le registre Internet régional pour l'Afrique et une partie de la région de l'océan Indien (Seychelles, Maurice, Madagascar, Comores). Il est chargé de distribuer l'espace d'adressage Internet public et les ressources connexes (y compris les numéros de système autonome) dans la région et de coordonner l'élaboration et la mise en œuvre des politiques de gestion de ces ressources.

Les politiques décrites dans ce document ont été développées par la communauté Internet grâce à un processus de consensus facilité par AFRINIC. Ils doivent être mis en œuvre par AFRINIC.


7.2  Objectif

Ce document décrit 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. Ces politiques s'appliquent à IPv4 et IPv6 les réseaux. Les politiques d'autres régions autres que la région de service AFRINIC n'entrent pas dans le cadre de ce document.


7.3  Définitions

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 dans le cadre d'une politique de routage unique et clairement définie.
  2. Numéro du système autonome (ASN) - Un numéro de système autonome (ASN) est un entier unique associé à un AS.  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.
  3. Réseau multi-hébergé - Un AS multirésident est un AS connecté à plus d'un autre AS. Un AS est également qualifié de multi-hébergé s'il est connecté à un point d'échange Internet public.
  4. 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.
  5. 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.4  Admissibilité à l'attribution d'un numéro AS

Il est important de déterminer quels sites nécessitent des numéros AS uniques et ceux 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é. Ces numéros sont les suivants: 64512 à 65535 (RFC1930).

Pour pouvoir prétendre à un numéro AS, l'organisation requérante doit remplir les conditions suivantes:

7.4.1 Une politique de routage unique (sa politique diffère de ses homologues de la passerelle frontalière).

7.4.2 Un site multi-hébergé.

7.4.3 Une organisation sera également éligible si elle peut démontrer qu'elle satisfera aux critères ci-dessus lorsqu'elle recevra ASN (ou dans un délai raisonnablement court par la suite).

7.4.4 Etre membre d'AFRINIC en règle (type utilisateur final ou LIR)

Toutes les demandes de ASNs selon ces critères seront évalués en utilisant les lignes directrices décrites dans la RFC1930 «Lignes directrices pour la création, la sélection et l'enregistrement d'un système autonome (AS).


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

7.5.1 Propriété

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.5.2 Considérations relatives au 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.6  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.4 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.6.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.6.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.7  Exigences en matière d’enregistrement

Voir Tout 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.7.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 qui est responsable du fonctionnement quotidien de cet AS.

7.7.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.7.3 Mise à jour des détails 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.8  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.9  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 sur les meilleures pratiques qui encourage tous les membres à utiliser activement l'objet pour publier des informations de contact 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 la délégation inverse, 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 mapper vers un nom de domaine à partir d'une adresse IP. La délégation inverse est obtenue par l'utilisation de in-addr.arpa (IPv4) et ip6.arpa (IPv6) domaines.


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

AFRINIC accepte uniquement les demandes de délégation inversée sous in-addr.arpa des LIR AFRINIC actifs. Les utilisateurs finaux doivent envoyer leurs demandes au LIR à partir 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 pour la zone pour laquelle la délégation inverse est demandée est en place et configuré conformément aux recommandations de la 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 pour que le domaine ip6.arpa soit utilisé pour le mappage d'adresse en 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. 

Ne pas avoir IPv4 des adresses pour développer ou démarrer de nouveaux IXP créeraient une complexité de routage inutile et inutile pour les réseaux connectés à Internet, cherchant à regarder les IXP pour étendre leur réseau.

AFRINIC a déjà une politique existante pour faire des allocations aux IXP [1], mais cette politique ne réserve pas spécifiquement IPV4 espace pour s'assurer qu'il y en aura, pour que les futurs IXP se développent et se développent. De plus, cette politique réserve un ensemble de ASNs entre 0 et 65535 pour une utilisation par les IXP, pour les serveurs de routage IXP BGP. 


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 d'un réseau, il est donc souhaitable que l'espace "LAN d'appairage" soit fourni à partir d'un bloc contigu. Le LAN de gestion de l'IXP est le réseau de gestion utilisé par l'IXP pour fournir des services sur l'IXP, comme la surveillance, les statistiques, le courrier, les systèmes de tickets, l'approvisionnement du transit vers les racines DNS, etc. Les réseaux de gestion sont censés être accessibles à l'échelle mondiale, par exemple pour publier des données et permettre l'accès à distance à une bonne infrastructure de réseau (comme les serveurs DNS racine et TLD) et à des projets de recherche. 


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 routage mettent en œuvre la politique de routage IXP sous la forme de communautés BGP, généralement sous la forme A: B, où A, B représentent A = serveur de routage IXP BGP et B = participant ASN. 

Les implémentations BGP actuelles utilisent 6 octets pour l'attribut de communauté étendue. Par conséquent, un IXP avec un octet 4 ASN en cours d'utilisation sur son serveur de routage ne serait pas en mesure de mettre en œuvre avec succès le mappage de communauté BGP A: B, si un participant IXP a un octet de 4 octets ASN. Cette situation est susceptible d'être vécue par plus d'IXP, comme 4 octets supplémentaires ASNs sont attribués dans le cadre du processus AFRINIC actuel. 

Si les communautés de serveurs de routage IXP incluent l'ASN participant à l’IXP et l'ASN du pair (qui devrait être 4 octets) et que seulement 6 octets au total sont disponibles, l'ASN des serveurs de routage IXP ne pourra pas dépasser 2 octets. 


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 affectations pour les réseaux locaux homologues IXP doivent provenir d'un bloc dédié, publié comme tel par AFRINIC. Les attributions de Peering LAN pour chaque IXP doivent garantir que le bloc IP adjacent / 24 est réservé (sur la base de la taille minimale de la politique d'attribution de l'utilisateur final de / 24) pour prendre en charge la croissance future de l'IXP. Cela permettra à un IXP d'augmenter ses ressources LAN d'appairage à / 23 sans avoir à renuméroter vers une nouvelle allocation de bloc IP contiguë. 

Les assignations d’adresses de gestion IXP NE DOIVENT PAS être effectuées à partir du même bloc que celui des LAN d’échange IXP. 

Il est proposé qu'un bloc / 16 soit réservé pour les besoins futurs des réseaux locaux homologues IXP dans la région de service AFRINIC, et qu'AFRINIC publie ce bloc en tant que tel. De plus, les attributions pour le réseau local homologue IXP devraient réserver le bloc IP contigu / 24 adjacent au IXP demandeur pour une croissance future.

Ces réservations seront maintenues jusqu'à ce que le pool disponible des / 16 ne puisse plus attribuer / 23 affectations. Par la suite, de nouvelles demandes peuvent être attribuées à partir de l'espace réservé détenu pour la croissance future de l'IXP. Il est en outre proposé de réserver l'équivalent d'un bloc / 16 supplémentaire pour les préfixes de gestion IXP, distinct des réseaux locaux d'appairage. 

Il est proposé que AFRINIC réserve un bloc de ASNs entre 0 et 65535 XNUMX pour une utilisation dans les serveurs de routage BGP des points IXP dans la région de service AFRINIC. Le nombre de ASNs à réserver doit être le plus élevé de 114, ou la moitié du reste ASNs entre 0 et 65535 dans le bloc d'AFRINIC à la date de ratification de cette politique. AFRINIC allouera ces ressources sur la base du premier arrivé, premier servi. 


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 envisagera toute diffusion IPv4/IPv6 blocs attribués pour être «pleinement utilisés» par le LIR lors de l'examen de l'utilisation pour la première allocation ou pour une allocation 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-alloués. Ils doivent être étiquetés avec l'attribut status dans l'AFRINIC whois service comme "ASSIGNED ANYCAST".

Dernière modification le -
Date et heure à Maurice -