| Détails |
|
1) Résumé
Ce document décrit les directives pour IPv4 la répartition et l'attribution des adresses dans la région de service AFRINIC (Afrique et partie de l'océan Indien) .Elles ont été élaborées dans le cadre d'un processus d'élaboration des politiques ouvert et ascendant du Groupe de travail sur les politiques d'AFRINIC.
2) Introduction
AFRINIC (The African Network Information Center) est une organisation indépendante à but non lucratif qui fait partie des cinq registres Internet régionaux (RIR's). Sa région de service comprend le continent africain et une partie de l'océan Indien (Seychelles, Maurice, Madagascar, Comores). AFRINIC est responsable de l'attribution de l'espace d'adressage IP (Internet Protocol), des numéros AS (Autonomous System) et de la gestion des noms de domaine inversés dans la région.
3) Portée
Ce document décrit les politiques de gestion responsable des IPv4 espace d'adressage dans la région AFRINIC. Les politiques de ce document s'appliquent à tous IPv4 les attributions et les affectations dans la région de service AFRINIC et doivent être mises en œuvre par tous les registres Internet locaux d'AFRINIC.
Ce document ne décrit pas les politiques liées à IPv6, Numéros AS, adresses privées et domaines in-addr.arpa. Ces politiques peuvent être consultées sur http://www.afrinic.net/en/library/policies/current
Il ne décrit pas les conditions d’adhésion à AFRINIC décrites au http://www.afrinic.net/en/services/rs il n'examine pas non plus les politiques des autres registres régionaux d'Internet.
4) IPv4 espace d'adressage
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:
une. Les adresses IP publiques / globales qui sont attribuées pour être globalement uniques selon les objectifs décrits dans la section 6 de ce document.
b. Privé IPv4 l'espace d'adressage est réservé pour une utilisation en privé IPv4 les réseaux. N'importe qui peut utiliser ces adresses dans ses réseaux privés sans inscription. Hôtes avec privé IPv4 les adresses ne peuvent pas être atteintes à partir d'Internet à moins qu'elles ne soient 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 / techniques de l'utilisation de NAT. La RFC1918 décrit également les blocs réservés à un usage privé.
c. Plages IP réservées aux expériences: celles-ci sont décrites dans la RFC3330 (http://www.ietf.org/rfc/rfc3330.txt). Certaines plages sont également réservées à la multidiffusion.
5) Hiérarchie de la distribution de l'espace d'adressage
Les adresses IP sont réparties dans une structure hiérarchique dans laquelle l'IANA (The Internet Assigned Numbers Authority) alloue un espace d'adressage à AFRINIC, pour être redistribué dans toute la région africaine. AFRINIC alloue un espace d'adressage aux registres Internet locaux (LIR) et leur délègue également le pouvoir de faire des attributions et des sous-allocations. Les LIR sous-allouent et attribuent un espace d'adressage à leurs clients conformément aux politiques et procédures décrites dans ce document.
6) Définitions
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.
6.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.
6.2 Registre Internet régional (RIR)
Auparavant, les registres Internet régionaux (RIRs) ont été créés sous l'autorité et les initiatives des communautés Internet dans leurs régions respectives. Actuellement, l'ICANN autorise la création de RIRs servir et représenter de grandes régions géographiques.
Le rôle principal de RIRs est de gérer et de distribuer l'espace d'adressage Internet public dans leurs régions respectives.
Actuellement, il y a quatre RIRs: APNIC, ARIN, LACNIQUE, RIPE NCC. AFRINIC est le cinquième
6.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.
6.4 Attribution
« Attribuer » signifie distribuer l'espace d'adressage aux LIR pour qu’eux-mêmes les distribuent par la suite.
6.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.
6.6 Assignation
Une affectation est un bloc IP donné par un LIR aux utilisateurs finaux pour leur propre usage. «Attribuer» signifie déléguer l'espace d'adressage à un FAI ou à un utilisateur final pour une utilisation spécifique au sein de l'infrastructure Internet qu'ils exploitent. Les affectations ne doivent être effectuées qu'à des fins spécifiques documentées par des organisations spécifiques et ne doivent pas être sous-affectées à d'autres parties.
Adresses IP dites « PA » (pouvant être agrégées par le fournisseur d’accès)
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é.
6.8 Zones d’adressage IP indépendantes
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.
7) Objectifs du système de registre Internet
7.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:
- Unicité - Afin que chaque hôte sur Internet public puisse être identifié de manière unique, chaque monodiffusion publique IPv4 l'adresse doit être unique au monde.
- Inscription - Chaque attribution et attribution 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.
- Agrégation - Distribution Ipv4 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).
- 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.
7.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 affectation permet de garantir que le processus reste transparent et honnête.
Documentation 7.3
Afin d'évaluer correctement les demandes, un RIR doit examiner attentivement toute la documentation pertinente relative aux réseaux en question. Cette documentation peut inclure des plans d'ingénierie de réseau, des plans de sous-réseau, 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.
7.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 existants et potentiels d'AFRINIC, quels que soient leur emplacement, leur nationalité, leur taille ou tout autre facteur.
8) Conditions d'inscription
a) Toutes les communications avec AFRINIC se feront en anglais.
b) Toutes les allocations et affectations seront enregistrées dans une base de données AFRINIC. Toute attribution / allocation / sous-allocation non enregistrée sera considérée comme non valide. 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.
Politiques et directives d'allocation
8.1 Introduction
AFRINIC alloue des gammes de IPv4 adresses aux registres Internet locaux (LIR). Les LIR réaffectent ou sous-allouent cet espace à leurs clients.
Une allocation est une gamme de IPv4 adresses à partir desquelles les sous-allocations et les affectations sont effectuées. 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.
La détermination de la taille d'allocation d'espace d'adresse IP est la responsabilité du personnel d'AFRINIC. Afin de garantir que le routage inter-domaines sans classe (CIDR) est implémenté et utilisé aussi efficacement que possible, AFRINIC émettra des blocs d'adresses sur les limites de bits appropriées "prises en charge par CIDR". (CIDR - "Classless Inter-Domain Routing", est expliqué dans la RFC1517-1959, http://www.ietf.org/rfc.htm).
Si un LIR prévoit d'échanger ou de transférer de l'espace d'adressage, il doit contacter AFRINIC pour 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.
8.2 Première attribution
a) L'allocation minimale d'AFRINIC est de / 22 ou 1024 IPv4 Adresses.
b) L'organisation doit être membre en règle d'AFRINIC, et
c) 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.
8.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 qu'un LIR reçoit sera de la taille de l'allocation pratique minimale décrite à la section 8.2 (a), 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 met 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.
8.4 Allocation supplémentaire
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.
Les réservations ne sont pas considérées comme des affectations ou des sous-allocations 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.
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.
8.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 l'espace au-dessus de sa fenêtre de sous-allocation (voir la section 10.0 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).
9) Politiques et directives d'affectation
Les LIR doivent demander l'approbation d'AFRINIC pour toutes les sous-allocations au-dessus de leur fenêtre de sous-allocation (voir la section 10.0 pour la politique SAW).
Les directives suivantes sont destinées à aider les LIR et les utilisateurs finaux dans leur recherche de compromis équitables:
Documentation 9.1
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 la sous-allocation précédente ne soit pas dupliquée, 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. Les formulaires de demande sont disponibles sur http://www.afrinic.net/en/library/policies/current
Lors de la sous-allocation de leur SAW, les LIR devraient également s'assurer que ces informations sont fournies par l'utilisateur final.
9.2 Infrastructure 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.
9.3 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%.
9.4 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é.
9.5 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.
9.6 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 prendre pour renuméroter complètement.
10) Fenêtre de sous-allocation (SAW)
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 de la SCIE est exprimée en notation CIDR.
AFRINIC examinera la sous-allocation faite par les LIR en utilisant leur SAW pour s'assurer que les politiques sont suivies correctement. Les LIR doivent é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.
Voici quelques directives pour le SAW:
10.1 Tous les nouveaux LIR ont un SAW de zéro. Toutes les sous-allocations devront être approuvées au préalable par AFRINIC.
10.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.
10.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:
- Toute la documentation requise est normalement présentée.
- Les affectations de sous-allocation précédentes de cette sous-allocation sont toutes enregistrées correctement dans la base de données.
- La SAW actuelle n'a pas été mal utilisée / abusée.
10.4 Il est conseillé aux nouveaux LIR de former leurs contacts pour gérer les affectations d'espace d'adressage conformément aux politiques et procédures du présent 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
11) 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:
- La demande d'origine.
- Documentation à l'appui.
- Correspondance connexe entre le LIR et l'utilisateur final.
- Décision de la mission et motifs de toute décision inhabituelle.
- Rôle de la personne qui a pris la décision.
12) Abréviations
- Centre d'information du réseau africain AFRINIC
- Centre d'information du réseau APNIC Asie-Pacifique
- Registre américain ARIN pour les numéros Internet
- Fenêtre de sous-allocation SAW
- Autorité IANA pour les numéros attribués à Internet
- Communauté Internet de l'ICANN pour les noms et numéros attribués
- Protocole Internet IP
- Centre d'information du réseau LACNIC d'Amérique latine et des Caraïbes
- Registre Internet local LIR
- Fournisseur PA regroupable
- Indépendant fournisseur PI
- RIR Registre Internet régional
13) Liens utiles
- Documents RFC: http://www.ietf.org/rfc.html
- Site Web de l'IANA: http://www.iana.org
| Notre Histoire | |
| 09.02.2004 | Initiales draft posté sur le groupe de travail politique AFRINIC (policy-wg [at] afrinic.org le précurseur de rpd) par Ernest Byaruhanga. |
| 13.02.2004 | Le kit de préparation mis à jour draft posté sur policy-wg [at] afrinic.org. C'est la première fois que le groupe est ouvert à la communauté. Jusqu'à présent, il a été fermé. |
