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

IPv4 Attribution et attribution d'adresses | AFPUB-2013-V4-002-DRAFT- 01

 

Détails
  • Réf. Prénom:
    AFPUB-2013-V4-002-DRAFT- 01
  • Modifie:
    AFPUB-2005-v4-001
  • Statut:
    Retiré
  • Date :
    22 Jan 2013
  • Auteurs):
    S. Moonesamy,
    cette adresse e-mail qui est protégée du spam. Vous devez activer JavaScript pour la voir.
  • Évaluation du personnel

Résumé

Ce document décrit la politique de IPv4 Adresse des attributions et des affectations dans la région de service AFRINIC.

1) Introduction

AFRINIC (African Network Information Center) est le registre Internet régional (RIR) pour la région de service AFRINIC. Il est responsable de l’attribution des IPv4 l'espace d'adressage dans la région de service africaine.

L’Internet Assigned Numbers Authority (IANA) attribue des parties de la IPv4 adresse l'espace à AFRINIC pour la distribution dans la région de service AFRINIC. Ce document décrit la politique de IPv4 Attribution et attribution d'adresses dans la région de service AFRINIC.

La première politique pour IPv4 attribution d'adresse (AFPUB-2005-v4-001) a été adopté en mai 2006. Ce document reprend l'expérience acquise dans la répartition des IPv4 adresses depuis 2006. Il est obsolète AFPUB-2005-v4-001.

 

2) Définitions

2.1) IPv4 Adresses

IPv4 les adresses ont une longueur fixe de quatre octets (32 bits). Ce document fait référence à IPv4 adresses administrées par AFRINIC telles que documentées dans l'IANA IPv4 Registre de l'espace d'adressage [REG].

2.2) Registre Internet

Un registre Internet est une organisation chargée de distribuer l'espace d'adressage IP à ses clients et d'enregistrer ces adresses. Les registres Internet sont classés selon leur fonction principale.

2.3) Registre Internet régional

Un registre Internet régional (RIR) opère dans une grande région géopolitique telle qu'un continent. Le but d'un registre Internet régional est de gérer et de distribuer des ressources de numéros Internet dans sa région de service.

2.4) Registre Internet local

Un registre Internet local (LIR) est un registre Internet qui reçoit des allocations d'un RIR et attribue principalement un espace d'adressage aux utilisateurs des services réseau qu'il fournit. Les utilisateurs sont des utilisateurs finaux et éventuellement d'autres fournisseurs de services Internet.

2.5) Fournisseur de services Internet

Un fournisseur de services Internet (ISP) attribue un espace d'adresse IP aux utilisateurs finaux d'un service réseau qu'il fournit. Ses clients peuvent être d'autres FAI.

2.6) Utilisateur final

Un utilisateur final ou un site final a une relation juridique ou commerciale (la même entité ou des entités associées) avec un fournisseur de services Internet.

2.7) Attribuer

Allouer fait référence à la distribution de l'espace d'adressage IP aux registres Internet locaux à des fins de distribution ultérieure.

2.8) Sous-allouer

«Sous-allouer» signifie que l'espace d'adressage IP sera distribué par les registres Internet locaux aux FAI en vue d'une distribution ultérieure.

2.9) Attribuer

Attribuer signifie déléguer l'espace d'adressage IP à un fournisseur de services Internet ou à un utilisateur final pour leurs opérations. Les affectations ne doivent être effectuées qu'à des fins spécifiques documentées par les organisations et ne doivent pas être sous-affectées à d'autres parties.

2.10) Espace d'adressage IP agrégable du fournisseur

L'espace d'adressage IP agrégable du fournisseur est l'espace d'adressage IP qui a été alloué aux LIR à partir desquels ils peuvent attribuer ou sous-allouer aux utilisateurs finaux, les réseaux en aval en tant que bloc non portable. Si l'utilisateur final ou le réseau en aval change de fournisseur (LIR), l'espace d'adresse IP attribué ou sous-alloué par le fournisseur précédent (LIR) doit être renvoyé et le réseau renuméroté.

2.11) Espace d'adressage IP indépendant du fournisseur

L'espace d'adresse IP indépendant (ou portable) du fournisseur ne peut pas être agrégé et ne peut être attribué que par un RIR via un LIR. L'espace d'adressage IP indépendant du fournisseur (PI) est coûteux à router et peut ne pas être routable globalement. Les sous-allocations ne peuvent pas être effectuées à partir de ce type d'espace d'adressage IP par l'utilisateur final ou LIR.

 

3) Système de registre Internet

Le système de registre Internet comprend les niveaux de hiérarchie suivants, vus de haut en bas: IANA, registres Internet régionaux, registres Internet locaux. Le système de registre Internet garantit l'unicité des ressources de numéros Internet et fournit des informations pour le dépannage Internet à tous les niveaux.

 

4) Objectifs

AFRINIC a le devoir d'agir en tant que dépositaire d'une ressource publique dans son administration IPv4 espace d'adressage. Il veille à ce que IPv4 l'espace d'adressage est réparti selon les objectifs suivants:

  • Unicité
  • Distribution équitable
  • Agrégation
  • Enregistrement

4.1 Unicité

Pour que chaque hôte de l'Internet public soit adressable à chaque monodiffusion publique IPv4 l'adresse doit être unique au monde.

4.2 Distribution équitable

IPv4 les adresses doivent être réparties équitablement en fonction des besoins opérationnels tout en tenant IPv4 adresses est une ressource finie.

Agrégation 4.3

Distribuer IPv4 les adresses de manière hiérarchique permettent 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.

4.4 Enregistrement

Chaque affectation et attribution de IPv4 l'espace d'adressage doit être enregistré dans l'AFRINIC Whois. Cela est nécessaire pour garantir l'unicité, la transparence et fournir des informations pour le dépannage Internet à tous les niveaux.

4.5 Objectifs contradictoires

Il est dans l'intérêt de la communauté Internet dans son ensemble que les objectifs ci-dessus soient poursuivis. Cependant, une distribution et une agrégation justes sont des objectifs contradictoires. Tous les objectifs ci-dessus peuvent parfois être en conflit avec les intérêts des registres Internet individuels ou des utilisateurs finaux. Les registres Internet évaluant les demandes d'allocations et d'assignations doivent analyser soigneusement toutes les considérations pertinentes pour rechercher un compromis approprié.

 

5) Documents

Le processus de prise de décision pour chaque affectation ou affectation doit être documenté pour garantir que le processus est équitable. La documentation doit être conforme aux pratiques bien connues. Les estimations et les prévisions doivent être réalistes et justifiables.

5.1 Langue

AFRINIC utilise l'anglais comme langue de travail.

 

6) Conditions d'inscription

Une attribution ou une cession est valable tant que les critères sur lesquels l’allocation ou l’affectation initiale était fondée sont toujours en place, que le but pour lequel la demande a été faite n’a pas changé et qu’elle est enregistrée dans l’AFRINIC. Whois. Les données d'enregistrement (nom, plage, coordonnées, statut, etc.) doivent être tenues à jour.

Une affectation, une allocation ou une sous-allocation non enregistrée est considérée comme non valide.

6.1 Annulation d'une inscription

L'un des éléments suivants peut être considéré comme un motif d'annulation de l'inscription:

(a) Défaut d'utiliser le IPv4 adresse dans un délai d'un mois à compter de son inscription.

(b) Non-respect des obligations contractuelles d'AFRINIC.

(c) Non-respect des décisions documentées de la communauté AFRINIC.

AFRINIC informe la communauté que le IPv4 le bloc d'adresse est à nouveau disponible.

 

7) IPv4 Lignes directrices sur l'attribution des adresses

An IPv4 l'allocation est une gamme de IPv4 adresses à partir desquelles des affectations ou des sous-allocations sont effectuées. Afin de garantir que le routage inter-domaines sans classe (CIDR), tel que décrit dans le BCP 122 [BCP122], 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". Une assignation LIR IPv4 l'espace d'adressage alloué par AFRINIC doit adopter des politiques cohérentes avec ce document.

7.1 Attribution initiale

L'allocation initiale minimale est de a / 22 IPv4 longueur du préfixe d'adresse.

La justification est fondée sur une combinaison de besoins immédiats et d'utilisation IPv4 adresses. Missions existantes de IPv4 les adresses doivent être renumérotées dans la nouvelle attribution du LIR.

Vérification de l'utilisation existante de IPv4 les adresses sont basées sur les assignations et sous-allocations enregistrées dans l'AFRINIC, l'APNIC, l'ARIN, le LACNIC et le RIPE Whois et seules ces cessions enregistrées seront considérées comme valides.

Une allocation initiale minimale peut également être envisagée si un fournisseur de services Internet s'interconnecte avec d'autres réseaux à un point d'échange Internet dans la région de service AFRINIC qui a une politique ouverte. Des informations supplémentaires peuvent être demandées pour justifier l'allocation.

7.2 Mécanisme de démarrage lent pour les allocations initiales

Le mécanisme de démarrage lent consiste à empêcher les allocations de gros blocs de IPv4 espace d'adressage qui peut alors rester sensiblement non affecté.

Un mécanisme de démarrage lent doit être appliqué à un nouveau LIR. L’allocation initiale faite par AFRINIC à un LIR sera de la taille du IPv4 préfixe d'adresse décrit à la section 7.1, sauf justification contraire.

7.3 Allocation supplémentaire

Les demandes d’allocation supplémentaire seront prises en considération si environ 80% de IPv4 l'espace d'adressage actuellement alloué au LIR a été utilisé pour des assignations et / ou des sous-allocations valides. Une nouvelle demande d'allocation peut également être envisagée si une assignation ou une sous-allocation nécessite plus d'adresses que le nombre de IPv4 adresses 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 conserver IPv4 blocs d'adresse gratuits pour la croissance future. Ces réservations internes ne sont cependant pas considérées comme une utilisation valable et doivent être attribuées ou sous-allouées avant de demander une allocation supplémentaire.

Contigu IPv4 des plages d'adresses doivent être allouées pour permettre au LIR de minimiser le nombre d'annonces d'itinéraire qu'il fait. Cependant, il n’est pas toujours possible d’attribuer un IPv4 plage d'adresses contiguë à l'allocation précédente du LIR.

7.4 Sous-allocations

Le minimum IPv4 la longueur du préfixe d'adresse d'une sous-allocation est a / 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 d'adressage au-dessus de sa fenêtre de sous-allocation (voir la section 9 pour la fenêtre de sous-allocation).

Les LIR peuvent effectuer des sous-allocations à plusieurs FAI en aval. (Les FAI en aval utilisant efficacement une sous-allocation peuvent recevoir un / 22 IPv4 adresse longueur du préfixe s'ils souhaitent devenir un LIR).

Le LIR est chargé de veiller à ce que IPv4 l'espace d'adressage qui lui est alloué, puis le IPv4 l'espace d'adressage qu'il sous-alloue est utilisé conformément aux décisions documentées de la communauté AFRINIC [PDP].

Il est recommandé que les LIR utilisent le mécanisme de démarrage lent pour les sous-allocations aux FSI en aval. C’est pour s’assurer que IPv4 l'espace d'adressage sous-alloué est utilisé efficacement. Il peut aider le LIR à déterminer si les FAI en aval fonctionnent conformément aux décisions de la communauté AFRINIC documentées.

Les sous-allocations font partie de l'agrégation d'un LIR IPv4 espace d'adressage. Une LIR veille à ce que IPv4 l'espace d'adressage n'est pas sous-alloué à un FAI en aval si le FAI en aval n'est plus connecté au réseau du LIR (les sous-allocations ne sont pas portables).

7.5 Allocation maximale

L'allocation maximale recommandée est de / 10 IPv4 longueur du préfixe d'adresse.

 

8) IPv4 Lignes directrices d'affectation

Une LIR doit obtenir l'approbation de l'AFRINIC pour toutes les sous-allocations au-dessus de sa fenêtre de sous-allocation (voir la section 9 pour la fenêtre de sous-allocation).

Lorsqu'un LIR effectue une sous-allocation à partir de sa fenêtre de sous-allocation, il doit fournir les informations à l'utilisateur final.

AFRINIC peut demander des informations sur IPv4 répondre aux besoins, à l'infrastructure réseau et aux plans futurs pour vérifier l'utilisateur final IPv4 répondre aux exigences. Afin de garantir que les sous-allocations précédentes ne sont pas dupliquées, des informations sur les IPv4 l'utilisation de l'espace d'adressage est requise.

La quantité d'informations requises dépend de la taille de la demande et de la complexité du réseau. Des conseils pour faciliter les demandes devraient être accessibles au public.

8.1 Utilisation

L'utilisation immédiate des affectations doit représenter au moins 25% de l'affectation IPv4 espace d'adressage. Après une année civile, sauf circonstances particulières, elle devrait être d'au moins 50%.

8.2 Réservations non prises en charge

Les utilisateurs finaux ne peuvent pas réserver IPv4 l'espace d'adressage basé sur des plans à long terme car cela affecte la distribution équitable et fragmente le IPv4 l'espace d'adressage lorsque les prévisions initiales ne sont pas satisfaites. Une assignation LIR IPv4 l'espace d'adressage aux utilisateurs finaux doit effectuer les affectations à partir de tout espace d'adressage non alloué ou non attribué qu'il détient actuellement. Tout IPv4 l'espace d'adressage réservé par un LIR à ses utilisateurs finaux est considéré comme inutilisé.

8.3 Renumérotation

Les affectations valides peuvent être remplacées par le même nombre de IPv4 adresses si les critères d'attribution d'origine sont toujours remplis. le IPv4 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.

Un LIR disposera d'un délai pouvant aller jusqu'à trois mois pour migrer vers le nouveau IPv4 espace d'adressage. Le LIR peut demander un délai supplémentaire s'il existe une justification appropriée. Une fois qu'un réseau a été renuméroté, AFRINIC supprimera l'ancienne affectation de l'AFRINIC Whois.

8.4 Infrastructure réseau des réseaux LIR vs utilisateurs finaux

IPv4 les adresses utilisées uniquement pour connecter un utilisateur final à un LIR (par exemple, des liaisons point à point) sont considérées comme faisant partie de l'infrastructure du LIR. Ces adresses doivent être enregistrées dans le cadre de l'infrastructure du LIR.

Les sous-allocations effectuées par un LIR à un utilisateur final doivent être enregistrées dans AFRINIC Whois. Ce IPv4 l'espace d'adressage doit être enregistré auprès des contacts de l'utilisateur final. Si l'utilisateur final est un individu plutôt qu'une organisation, le IPv4 l'espace d'adressage peut être enregistré avec les coordonnées du LIR mais avec l'utilisateur final référencé dans l'AFRINIC Whois objet de base de données.

 

9) Fenêtre de sous-allocation

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 effectuée par le LIR à l'aide de sa SCIE pour la conformité. Une LIR doit s'assurer que la documentation de la sous-allocation effectuée à l'aide du SAW est similaire à celle demandée pour les demandes plus importantes.

9.1 Directives de la fenêtre de sous-allocation

Les directives pour la fenêtre de sous-allocation (SAW) sont les suivantes:

(a) Un nouveau LIR a un SAW de zéro. Le LIR doit demander l'approbation d'AFRINIC pour les sous-allocations.

(b) Un LIR ne peut effectuer aucune sous-allocation à l'utilisateur final au-dessus de sa SAW dans une période de 12 mois (une année civile). À la fin d'une année civile à compter de l'approbation d'une SAW, la SAW est actualisée pour une année civile de plus. 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.

(c) Une LIR peut demander à AFRINIC de revoir sa SCIE. 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 SAW, les éléments suivants doivent être 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 ou abusée.

Une LIR doit s'assurer que ses utilisateurs finaux gèrent IPv4 les attributions d'espace d'adressage conformément à ce document. Si des erreurs se produisent à plusieurs reprises, la SCIE peut être abaissée ou supprimée. Le SAW peut également être abaissé ou retiré pendant ou après un audit si des affectations non valides sont notées.

 

10) Tenue de registres

Une LIR doit conserver et conserver des enregistrements concernant les assignations et les sous-allocations à ses utilisateurs finaux. Ces enregistrements peuvent être utilisés pour évaluer les demandes faites par le LIR ou pour tout audit effectué par AFRINIC. Pour plus de commodité, les documents devraient être accessibles sous forme électronique. Il est recommandé que les enregistrements comprennent, sans s'y limiter:

a) La demande initiale.

(b) Documents justificatifs.

(c) Correspondance connexe entre le LIR et l'utilisateur final.

d) La décision d'affectation, y compris les raisons de toute décision inhabituelle.

e) Rôle de la personne qui a pris la décision.

L'historique des événements et les personnes responsables doivent être clairs.

 

11) Remerciements

L'auteur tient à remercier Adiel A. Akplogan et Ernest Byaruhanga pour la plupart des textes copiés de AFPUB-2005-v4-001

.

 

12) Références

 

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