IPv4 Atterrissage en douceur BIS (Draft 5)

Proposition

1.0) Résumé du problème traité par cette proposition de politique

La politique d'atterrissage en douceur ratifiée par le conseil le 11/11/2011 décrit comment AFRINIC devrait gérer les allocations / affectations depuis le dernier / 8. Il définit 2 phases de IPv4 épuisement. Pendant la phase 1, il définit le maximum à / 13 au lieu de / 10 et dans la phase 2, le maximum à / 22 et le minimum à / 24. Cela ne fait aucune différence entre les LIR ou les utilisateurs finaux existants et les nouveaux. La politique n'impose pas non plus IPv6 déploiement.

 

IPv4 l'épuisement dans d'autres régions combiné à d'autres facteurs a imposé une énorme pression sur l'AFRINIC IPv4 pool avec des demandes de grandes IPv4 blocs, avec très peu IPv6 déploiement. La pression sur l'AFRINIC IPv4 Le pool a conduit à certaines propositions politiques pour réserver des blocs à certaines sous-communautés.

 

2.0 Résumé de la façon dont cette proposition résout le problème

Cette proposition de politique résout le problème décrit ci-dessus en:

• Modification de la valeur des allocations / tailles d'affectation maximales pendant les phases d'épuisement 1 et 2.
• Réserver un bloc dédié pour faciliter IPv6 déploiement.

 

3.0 La proposition

3.1 Section du manuel des politiques qui sera touchée:

La section 5.4 du CPM sera remplacée comme suit:

 

5.4 Atterrissage en douceur

Cette proposition 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 (102/8) de IPv4 espace d'adressage. Le but de cette politique est de garantir 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

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.

L'application de la politique «d'atterrissage en douceur» commence lorsque AFRINIC commence à allouer de l'espace à partir du dernier IANA alloué / 8 (102/8).

 

5.4.1 La finale / 8

Le bloc Final / 8 de IPv4 l'espace d'adressage, ou "Final / 8", est le bloc / 8 de IPv4 l'espace d'adressage qui a été alloué par l'IANA à AFRINIC conformément à la section 2.2c de la Politique mondiale pour l'allocation des IPv4 Espace d'adressage - http://www.icann.org/en/general/allocation-remaining-ipv4-space.html.

Dans cette section relative à la politique d'atterrissage en douceur, «last / 8» et «102/8» doivent être utilisés de manière interchangeable.

 

5.4.2 Phase de pré-épuisement

La «phase de pré-épuisement» était la période pendant laquelle AFRINIC a attribué ou attribué IPv4 adresses aux LIR et aux utilisateurs finaux en utilisant la section 5.0 du manuel des politiques et avant le déclenchement de la phase d'épuisement.

Cette phase s'est terminée lorsque AFRINIC a annoncé publiquement (https://www.afrinic.net/en/library/news/2053-afrinic-enters-ipv4-exhaustion-phase-1) que la phase d'épuisement a commencé.

 

5.4.3 Phases d'épuisement

Pendant la phase d'épuisement, la politique d'allocation et d'affectation suivante sera utilisée. Cela s'applique aux LIR et aux utilisateurs finaux, et s'applique à tous 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.

Au cours de l'une des phases ci-dessous, toutes les allocations et affectations de IPv4 l'espace sera basé sur un besoin justifié et démontré.

La phase d'épuisement sera divisée en deux parties:

 

5.4.3.1 Phase 1 d'épuisement

5.4.3.1.1 Au cours de cette phase, l’attribution / l’attribution IPv4 l'espace d'adressage continuera comme dans Pré-épuisement avec le minimum fixé à / 24, mais le maximum passera de / 10 à / 18, sous réserve des dispositions du 5.4.6

5.4.3.1.2 Les attributions et les affectations se feront à partir du final / 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.

5.4.3.1.3 Pour éviter tout doute, toutes les demandes en cours à ce stade seront évaluées conformément à la nouvelle politique. 

 

5.4.3.2 Phase 2 d'épuisement

La phase d'épuisement 2 commencera lorsque pas plus d'un / 11 d'espace non réservé sera disponible à partir du final / 8. Au cours de cette phase, la taille maximale d'allocation / affectation sera / 22 et le minimum restera à / 24, sous réserve des dispositions du 5.4.6.

 

5.4.4 Fenêtre de planification de huit (8) mois (période d'allocation et d'affectation).

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

 

5.4.5 Critères d'attribution

5.4.5.1 Pour recevoir IPv4 allocations ou affectations pendant la phase d'épuisement, le LIR ou l'utilisateur final doit IPv4 les allocations ou les exigences de la politique d'attribution (en démontrant et en justifiant le besoin d'espace demandé) et doivent démontrer qu'ils ont utilisé efficacement au moins 90% de toutes les allocations ou affectations précédentes (y compris celles faites pendant la phase de pré-épuisement et d'épuisement).

5.4.5.2 Dans le cas de nouveaux LIR ou utilisateurs finaux (ceux qui n'ont pas d'allocations ou d'affectations antérieures avant la phase d'épuisement), cette exigence ne s'applique pas à leur première demande d'allocation ou d'affectation.

5.4.5.3 Les ressources AFRINIC sont destinées à la région de service AFRINIC et toute utilisation en dehors de la région doit être uniquement destinée à soutenir la connectivité vers la région AFRINIC

5.4.6 Limites admissibles et sous-séquence

 

5.4.6.1 Lorsqu'une organisation demande des informations supplémentaires IPv4 l'espace d'adressage dans les phases 1 et 2, les allocations / affectations totales d'une telle organisation ne doivent pas dépasser le préfixe maximum autorisé de / 18 pour la phase d'épuisement 1 et / 22 pour la phase d'épuisement 2.

5.4.6.2 Nonobstant le 5.4.6.1, une organisation qui a reçu le préfixe maximal autorisé dans chaque phase ne peut demander un autre cycle d'allocation / affectation dans la même phase (conformément au 5.4.6.1) qu'après une période d'attente de 24 mois civils.

 

5.4.7 IPv6 réserve de déploiement

Un contigu / 12 IPv4 bloc d'adresse sera réservé hors de la finale / 8 pour faciliter IPv6 déploiement. Lorsque AFRINIC ne peut plus répondre à des demandes d'espace d'adressage (de la finale / 8 ou de tout autre espace d'adressage disponible), les allocations et affectations de ce bloc doivent être justifiées par les besoins de IPv4 adresse l'espace à supporter IPv6 déploiement. Exemples de tels besoins: [IPv4 adresses des serveurs DNS à double pile des fournisseurs de services DNS principaux, des traducteurs 464XLAT ou de tout autre traducteur tel que défini par l'IETF. Ce bloc sera soumis à une allocation de taille maximale de / 24.

 

5.4.7.1 Le personnel d'AFRINIC fera usage de son pouvoir discrétionnaire lors de l'évaluation des justifications et devrait utiliser une allocation parcimonieuse si possible dans ce bloc / 12.

 

5.4.7.2 Afin de recevoir une allocation ou une mission du IPv6 réserve de déploiement:

5.4.7.2.1 Le demandeur peut ne pas avoir reçu de ressources en vertu de cette politique au cours des six (6) mois précédents;

5.4.7.2.2 Le demandeur doit démontrer qu'aucune autre affectation ou affectation ne répondra à ce besoin.

5.4.7.2.3 Exceptionnellement pour cela IPv6 réserve, les fournisseurs de services DNS de base tels que définis au 5.6.4.4.2 incluront également les ccTLD africains sanctionnés par l'ICANN opérant dans la région de service AFRINIC.

 

4. Remerciements

Nous remercions les auteurs du Atterrissage en douceur – SD proposition de politique et la communauté pour leurs contributions.

 

5. Historique des révisions

09 Février 2016	AFPUB-2016-V4-001-DRAFT01 (Version 1.0) Version 1 publiée sur la liste de diffusion rpd
16 Février 2016	AFPUB-2016-V4-001-DRAFT02 (version 2.0): Une nouvelle version complète de la section 3 et donc la proposition de politique rend désormais obsolète IPv4 Politique d'atterrissage en douceur au lieu de la modifier.
22 JUL 2016	AFPUB-2016-V4-001-DRAFT03 (version 3.0): La taille maximale de l'allocation / affectation est passée de / 15 à / 18 dans la phase 1 conformément aux discussions lors de la réunion de politique publique d'AFRINC-24 et au suivi des discussions sur la SPR.
14 APR 2017	AFPUB-2016-V4-001-DRAFT04 (version 4.0): Version mise à jour basée sur le consensus des discussions en ligne et AFRINIC-25. Formaté pour une insertion directe dans CPM «Phase actuelle» remplacée par «Phase de pré-épuisement» Plus de réserve directe pour les infrastructures Internet critiques Plus de réserve directe pour les nouveaux entrants Une réserve dédiée pour faciliter IPv6 déploiement
27 JUN 2017	AFPUB-2016-V4-001-DRAFT05 (version 5.0): Introduction de «Limites admissibles et récurrence» - clauses 5.4.6.1 et 5.4.6.2 (période d'attente de 24 mois pour un membre qui a reçu la limite d'allocation maximale par phase pour revenir pour plus d'espace). Taille minimale d'affectation / d'allocation restaurée en épuisement à / 24 Suppression de la définition de «fournisseur de services DNS de base» et d'autres définitions qui n'étaient pas nécessaires. Résolution de la plupart des problèmes dans le rapport d'évaluation du personnel de l'AFPUB-2016-V4-001-DRAFT04

 

6. Références

Politique globale d’allocation du solde IPv4 pool d'adresses:

http://www.AFRINIC.net/en/library/policies/135-afpub-2009-v4-001

 

Évaluation du personnel

Index: Considérations relatives à l'évaluation du personnel

Les problèmes suivants soulevés par le personnel d'AFRINIC dans son évaluation de Soft Landing BIS version 4 ont tous été traités dans la version 5 comme indiqué dans le tableau:

Question	Action
La définition de la "phase d'épuisement" n'est pas claire. La politique actuelle d'atterrissage en douceur la définit, mais la définition serait supprimée si cette proposition est adoptée, ce qui nous laisserait sans bonne définition.	Semble être bien défini en 5.4
Les liens HTML doivent être développés pour être visibles dans les versions texte ou imprimées de la proposition	N/D
Dans l'introduction du 5.4, la politique existante comporte trois paragraphes et la nouvelle un paragraphe. Il n'y a aucune explication pour laquelle les informations supplémentaires ont été supprimées.	5.4 a été reformulé pour inclure le texte omis.
Dans 5.4.1 "Définitions", pourquoi avons-nous une définition de LIR différente de celle du CPM 2.3? Nous préférerions voir toutes les définitions (générales) dans la section 2 du CPM - à moins qu'elles ne soient explicitement spécifiques à la section d'atterrissage en douceur du CPM	OK
Les définitions de "LIR existant" et "utilisateur final existant" ne sont pas claires. Il semble que les auteurs se réfèrent aux membres qui ont rejoint AFRINIC et ont reçu un espace d'adressage avant le début de la phase d'épuisement. Dans tous les cas, le reste de la stratégie n'utilise pas ces définitions, de sorte que les définitions pourraient être supprimées.	Les deux définitions ont été supprimées
La définition de «nouveau LIR» et «nouvel utilisateur final» signifie que quelqu'un qui se joint aujourd'hui sera classé comme «nouveau» et restera «nouveau» pour toujours. Est-ce là l'intention des auteurs? Dans tous les cas, la définition n'est utilisée qu'une seule fois, en 5.4.5. Il n'y a pas besoin d'une définition si le texte en 5.4.5 est écrit avec soin.	Nouvelle LIR / UE supprimée de 5.4.1 et 5.4.5 reformulée
Dans la définition de final / 8, nous suggérons aux auteurs de spécifier qu'il s'agit de 102.0.0.0/8.	OK
Au 5.4.2 - notez que le terme «phase actuelle» de l'ancienne politique d'atterrissage en douceur est renommé «phase de pré-épuisement». Le nom "phase de pré-épuisement" est meilleur, mais nous notons que certains autres documents peuvent avoir besoin d'être modifiés pour tenir compte du changement.	N/D
Au 5.4.3.1, par souci de cohérence, veuillez indiquer explicitement IPv4 dans "attribution / affectation de IPv4 espace d'adressage "	OK
Au 5.4.3.1, "l'attribution / l'attribution de l'espace d'adressage se poursuivra comme dans le pré-épuisement". Nous comprenons que les exigences existantes pour les besoins justifiés resteront. Nous suggérons de clarifier cela et de le relever de 5.4.3.1 à 5.4.3, afin qu'il s'applique à toutes les phases. Le texte du 5.4.5 "doit répondre IPv4 des allocations ou des politiques d’attribution "implique également un besoin justifié, mais là encore, il pourrait être plus clair.	Besoin justifié pour toutes les phases ajoutées au 5.4.3 (et également au 5.4.5)
Dans 4.5.3.1, "pas de minimum explicite" est un changement par rapport à l'ancienne politique d'atterrissage en douceur. "Pas de minimum explicite" implique que le minimum sera de / 32, mais le personnel préférerait conserver un minimum de / 24. L'attribution ou l'attribution de blocs inférieurs à / 24 entraînera des difficultés opérationnelles pour le personnel (ainsi que sur Internet en général) et nécessitera des changements de logiciel.	Minimum ajusté à / 24
Au 5.4.3.2, les auteurs devraient indiquer le début de la phase 2. Actuellement, le début de la phase 2 est sous-entendu par l'un des points du point 5.4.3.1, mais il serait préférable que le 5.4.3.2 énonce explicitement les conditions de démarrage de la phase 2.	Clarifié en 5.4.3.2
Dans 5.4.3.1 «Pour éviter tout doute, toutes les candidatures en cours à ce stade seront évaluées conformément à la nouvelle politique». Cela devrait probablement s'appliquer au début de la phase 2 ainsi qu'au début de la phase 1.	N/D
Au 5.4.3.2 "Il n'y a pas de limite explicite au nombre de fois qu'une organisation peut demander des IPv4 espace d'adressage pendant la période d'épuisement ". Veuillez préciser si cela s'applique uniquement à la phase 2 ou également à la phase 1. Le personnel est préoccupé par l'augmentation possible de la charge de travail causée par de petites demandes répétées du même membre, et suggérez une méthode de limitation des taux devrait être ajouté, comme une limite au nombre de demandes par an.	«Sous réserve des dispositions du 5.4.6» a été ajouté aux deux phases.
5.4.7 réserve a / 12 pour faciliter IPv6 déploiement. Qu'arrive-t-il au / 12 qui était réservé par l'ancienne politique d'atterrissage en douceur pour "certaines utilisations futures, encore imprévues"? Nous pensons que l'ancienne réservation est annulée et que la nouvelle réservation la remplace, mais nous souhaitons la clarté. Nous comprenons également que l'espace réservé ne serait pas touché tant qu'aucun autre espace n'est disponible, et si l'espace d'adressage est ensuite retourné à AFRINIC (après que la réserve commence à être utilisée), l'espace retourné serait traité selon les règles de la phase 2 .	Laissez au personnel. L'ancien / 12 peut être reporté comme la même réservation.
Au 5.4.7, «le personnel d'AFRINIC fera usage de son pouvoir discrétionnaire lors de l'évaluation des justifications et devrait utiliser une allocation parcimonieuse si possible dans ce bloc / 12». Veuillez séparer ces deux idées très différentes en au moins deux phrases, mais de préférence deux sous-sections numérotées distinctes.	OK
Les auteurs sont généralement invités à utiliser des sections numérotées au lieu de listes à puces, pour faciliter la référence dans les discussions ou la correspondance futures.	N/D
Il est également conseillé aux auteurs de faire en général un effort pour maintenir la numérotation de la nouvelle politique proposée alignée sur la numérotation de la politique actuelle du CPM.	N/D

---

 

ÉVALUATION DU PERSONNEL pour AFPUB-2016-V4-001-DRAFT05: IPv4 Atterrissage en douceur BIS (v5)

Proposition	AFPUB-2016-V4-001-DRAFT05
Titre	IPv4 Atterrissage en douceur BIS (v5)
URL	https://www.afrinic.net/fr/community/policy-development/policy-proposals/2153-ipv4-soft-landing-bis
évaluée	24th août 2017

 

1. Compréhension de la proposition par le personnel

1. Remplacement complet du courant IPv4 Politique d'atterrissage en douceur (remplace l'intégralité du CPM 5.4)
2. Prévoit des ressources pour les nouveaux LIR et les utilisateurs finaux, ce qui manque dans l'actuel CPM 5.4.
3. Crée un réservé et dédié (IPv4 / 12) bloc pour les entreprises ayant besoin IPv4 espace pour soutenir IPv6 déploiement.
4. Introduit de nouvelles valeurs pour les tailles d'allocation / affectation maximales comme suit:
   1. Phase 1: Maximum / 18, minimum / 24
   2. phase 2: Maximum / 22, minimum / 24
5. Met en place une période d'attente de 24 mois pour un membre qui a reçu la limite d'allocation maximale par phase. (Un membre doit attendre 24 mois avant de demander une autre allocation au cas où un tel membre aurait consommé son allocation maximale dans une phase donnée).

 

2. Commentaires du personnel

1. Le nouveau 5.4.3 proposé qui dit "au cours de l'une ou l'autre des phases ci-dessous, toutes les allocations et IPv4 l'espace sera basé sur un besoin justifié et démontré "pourrait être clarifié davantage pour faire référence à" un besoin justifié et démontré conformément aux politiques en vigueur dans la phase de pré-épuisement, en plus des restrictions qui s'appliquent pendant les phases d'épuisement ".
2. Le nouveau 5.4.6.1 proposé dit "Lorsqu'une organisation demande des informations IPv4 l'espace d'adressage dans les phases 1 et 2, le total des allocations / affectations d'une telle organisation ne doit pas dépasser le préfixe maximum autorisé de / 18 pour la phase d'épuisement 1 et / 22 pour la phase d'épuisement 2. "Ce texte fait référence au total des avoirs de l'organisation, mais nous pensons que l'intention était de se référer à l'espace supplémentaire que l'organisation a reçu pendant la phase 1, ou à l'espace supplémentaire reçu pendant la phase 2.
3. La manière dont le nouveau 5.4.6.2 proposé remplace 5.4.6.1 est difficile à comprendre. Nous suggérons le texte suivant, qui, nous l'espérons, exprime plus clairement l'intention des auteurs:

 

5.4.6.Limites autorisées 5.4.6.1 Au cours d'une période de 24 mois au cours de la phase d'épuisement 1, une organisation peut recevoir une ou plusieurs allocations / affectations totalisant l'équivalent de a / 18. 5.4.6.2 Au cours d'une période de 24 mois au cours de la phase d'épuisement 2, une organisation peut recevoir une ou plusieurs allocations / affectations totalisant l'équivalent de a / 22.

 

1. Au 5.4.7, nous soupçonnons que l'intention des auteurs est que la réserve au titre du 5.4.7.1 existant "pour certaines utilisations futures, encore imprévues" disparaisse et soit remplacée par la nouvelle réserve au titre du nouveau 5.4.7 proposé ". faciliter IPv6 déploiement. " en utilisant un texte similaire à:

 

"Un contigu / 12 IPv4 bloc d'adresse sera réservé hors de la finale / 8 pour faciliter IPv6 déploiement. Pour éviter tout doute, cela remplace la réservation / 12 pour une utilisation future qui était présente dans une version précédente du IPv4 politique d'atterrissage en douceur. "

 

1. En 5.4.7, «Ce bloc sera soumis à une allocation de taille maximale de / 24» ne spécifie pas de taille minimale. Veuillez spécifier la taille minimale. Si le minimum est inférieur à / 24, la mise en œuvre sera beaucoup plus difficile.
2. Au 5.4.7.2.3, veuillez préciser si les ccTLD sont limités aux TLD de code de pays à deux lettres, ou si les ccTLD IDN le sont également. https://www.iana.org/domains/root/db et https://www.icann.org/resources/pages/fast-track-2012-02-25-en, L'ICANN utilise le terme "IDN ccTLD" pour les IDN TLD associés aux noms de pays (tels que "جزائر." Ou "xn - lgbbat1ad8j" pour l'Algérie).

 

3. Commentaires du conseiller juridique

Aucun observé

 

4.Mise en œuvre

 

4.1 Chronologie et impact

AFRINIC mettra environ 2 mois à mettre en œuvre cette proposition après ratification. (Les actions de mise en œuvre sont listées en 4.2 ci-dessous).

 

4.2 Exigences de mise en œuvre

• Codification des nouvelles tailles minimales et maximales d'allocation dans MyAFRINIC et whois.
• Codification du « délai d'attente » en MyAFRINIC.
• Révision des formulaires de demande de ressources (en MyAFRINIC et NMRP).
• Mise à jour des documents de processus internes.
• Mise à jour de CPM sec 5.4, le cas échéant.