Détails
|
Transferts de ressources IPv4 Inter-RIR (portée complète) |
|||
|
ID: |
AFPUB-2019-IPv4-002-DRAFT02 |
Date de soumission: |
2nd Novembre 2019 |
|
Auteur : |
Jordi Palet Martínez jordi.palet sur theipv6company.com The IPv6 Company |
Version: |
2.0 |
|
Obsolètes: |
Modifie: |
CPM, modifier l'art. 5.7 |
|
Proposition
1.0 Résumé du problème traité par cette proposition
Cette proposition permet d’établir le mécanisme permettant le transfert des ressources IPv4 vers / en provenance d'autres régions et d'aligner AFRINIC sur un marché qui existe déjà et dans lequel nous accusons un retard, ce qui est négatif pour la région.
2.0 Résumé de la manière dont cette proposition aborde le problème
Ces dernières années, et avec l'épuisement des adresses IPv4 , plusieurs régions ont résolu ce problème, non seulement par des transferts au sein de la région elle-même, mais entre différentes régions. Cela permet de faciliter une dynamique sur le marché et en augmentant l'offre, en réduisant les prix.
Cependant, un mécanisme inter RIR n’a pas été mis en place chez AFRINIC, ce qui conduit la région à une situation de discrimination et de rareté des adresses, non seulement pour le RIR , mais sur le marché de la région, ce qui évite même que de nouvelles entreprises puissent s'implanter dans la région, faute d'adresses.
D’autre part, le fait qu’il n’existe pas de politique inter RIR qui n'empêche pas les transferts "sous la table" et suppose donc qu'il existe des ressources dont l'historique de leur enregistrement est perdu, ce qui est l'une des principales fonctions d'AFRINIC.
Cette proposition considère que de tels transferts devraient être autorisés pour les adresses IPv4 legacy et les non legacy. Dans le cas des ressources héritées, cela a l'avantage de permettre à ces ressources d'émerger et de les intégrer dans le RIR s système.
En outre, il est important de souligner que le déploiement d'IPv6 , dans certains cas, peut nécessiter de petits blocs d'adresses IPv4 pour les mécanismes de transition, ou augmenter considérablement leurs coûts, et de nombreuses entités AFRINIC pourraient donc être sérieusement désavantagées si elles n'ont pas accès à un marché mondial, comme c'est le cas actuellement.
Il ne fait aucun doute que l'acceptation de ce type de transfert comporte également des risques, et il est possible qu'une augmentation initiale des prix soit générée, qui serait rapidement alignée sur le reste du marché mondial, comme c'est généralement le cas avec des marchés équivalents.
Cette proposition permettrait des transferts bidirectionnels avec APNIC, ARIN, LACNIC et RIPE.
Il est suggéré que, en tant que mise à jour éditoriale du CPM, si cette politique est adoptée, la section 5.7 soit déplacée vers une nouvelle section (éventuellement 13), qui hébergera à l'avenir toutes les politiques liées aux transferts en un seul endroit. Cette modification éditoriale peut être effectuée par le personnel, renumérotant / réorganisant toutes les sections pertinentes, même en ajustant les titres / sous-titres pour la nouvelle section afin de mieux correspondre au texte adopté.
Proposition 3.0
Modifier l'article 5.7 du CPM comme suit:
|
Actuel |
Proposition |
|
5.7 IPv4 Transfert de ressources au sein de 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 du compte d'un membre AFRINIC existant ou d'un ancien détenteur de ressources dans la région de service AFRINIC.
|
5.7 IPv4 Transferts de ressources Cette politique s’applique à une organisation ayant des besoins justifiés, IPv4 ressources qui ne peuvent être satisfaites par AFRINIC. 5.7.1 Types de transfert reconnus Deux types de transferts sont reconnus: a) Intra-RIR. Les deux parties se trouvent dans la région de service AFRINIC. b) Inter-RIR. L'une des parties se trouve dans la région de service AFRINIC, tandis que l'autre est dans une autre RIR région de service.
|
|
5.7.3. Conditions relatives à la provenance du transfert 5.7.3.1 La source doit être le titulaire légitime actuel du IPv4 s'adresser aux ressources reconnues par AFRINIC, et ne pas être impliqué dans un différend quant au statut de ces ressources. 5.7.3.2 Les entités sources ne seront pas éligibles pour recevoir d'autres IPv4 traiter les allocations ou les affectations d'AFRINIC pour une période de 12 mois après l'approbation du transfert. 5.7.3.3 Les entités sources ne doivent pas avoir reçu de transfert, d'attribution ou d'attribution de IPv4 nombre de ressources d'AFRINIC pour les 12 mois précédant l'approbation de la demande de transfert. Cette restriction exclut les transferts de fusions et acquisitions.
|
5.7.2 Conditions sur la source du transfert 5.7.2.1 La source doit être le titulaire légitime actuel du IPv4 adresser les ressources dans les RIR, et ne pas être impliqué dans un différend quant au statut de ces ressources. 5.7.2.2 Les entités sources ne seront pas éligibles pour recevoir d'autres IPv4 adresser les allocations ou les affectations d'AFRINIC. 5.7.2.3 Les entités sources ne doivent pas avoir reçu de transfert, d'attribution ou d'attribution de IPv4 nombre de ressources d'AFRINIC pour les 12 mois précédant l'approbation de la demande de transfert. |
|
5.7.4. Conditions relatives au destinataire du transfert 5.7.4.1 AFRINIC doit approuver le besoin du bénéficiaire de IPv4 nombre de ressources. Pour qu’une organisation puisse prétendre à recevoir un transfert, elle doit d’abord passer par le processus de justification de IPv4 besoins en ressources avant AFRINIC. C'est-à-dire que l'organisation doit justifier et démontrer devant AFRINIC son utilisation initiale / supplémentaire d'allocation / affectation, le cas échéant, conformément aux politiques en vigueur. 5.7.4.2 Le bénéficiaire doit être un membre d'AFRINIC, sous réserve des politiques d'AFRINIC en vigueur et doit signer le Contrat de services d'inscription pour les ressources reçues.
|
5.7.3 Conditions du destinataire du virement 5.7.3.1 Pour une organisation de la région de service AFRINIC, AFRINIC doit approuver le besoin du bénéficiaire de IPv4 nombre de ressources, conformément aux politiques pertinentes existantes. 5.7.3.2 Pour une organisation dans un autre RIR région de service, le critère pertinent dépendra des politiques pertinentes dans la destination RIR. 5.7.3.3 Le destinataire doit être membre de la RIR, soumis à ses politiques et documents juridiques / accords de service. |
|
5.7.4.3 Transféré IPv4 les ressources héritées ne seront plus considérées comme des ressources héritées.
|
5.7.3.4 IPv4 les ressources héritées ne seront plus considérées comme des ressources héritées:
|
|
5.7.4 Dispositions pour ASN transferts En cas de transfert de la majorité des IPv4 ressources provenant de la source, des ASN(s) pourrait également être transféré, si d'autres politiques pertinentes sont respectées. |
|
|
5.7.5 Calendrier pour l'applicabilité de transferts inter-RIR Inter-RIR les transferts ne seront déclenchés qu'une fois qu'AFRINIC entrera dans la phase d'épuisement 2 (comme défini au 5.4.3.2). |
|
|
5.7.6 Transparence des transferts Chaque fois qu'un transfert est effectué, les informations pertinentes et non confidentielles seront automatiquement publiées sur une page Web spécifique, comprenant au moins: date du transfert, ressources transférées, organisation source et RIR, organisation de destination et RIR. |
|
|
5.7.8 Dispositions relatives aux suspensions de transferts 5.7.8.1 L’inter-RIR les transferts seront suspendus au cas où le nombre de IPv4 dépasse de 6 mois consécutifs les adresses entrantes. 5.7.8.2 Le personnel peut suspendre provisoirement toute opération suspecte et demander plus d'informations à toutes les parties, afin que le conseil d'administration puisse prendre une décision. |
4.0 Références
Il existe des politiques inter RIR d'APNIC, ARIN et RIPE, qui ont largement démontré leur efficacité et n'ont pas posé de problèmes aux communautés respectives, bien au contraire.
LACNIC est parvenu à un consensus sur une proposition équivalente lors de sa dernière réunion et est déjà mis en œuvre (prévu en juillet 2020):
Selon les preuves existantes, la région ARIN apparaît comme l'origine du transfert du plus grand nombre d'adresses vers les autres régions qui ont des politiques de transfert de ressources.
- https://www.nro.net/wp-content/uploads/NRO-Statistics-2018-Q4.pdf
- http://www.lacnic.net/innovaportal/file/3277/1/2-john-sweeting-arin.pdf
Historique des révisions
Historique des révisions
|
Date |
Détails |
|
14 mai 2019 |
Version 1 : AFPUB-2019-IPv4-002-DRAFT01 Initiales Draft Publié sur rpd |
|
2nd novembre 2019 |
Version 2 : AFPUB-2019-IPv4-002-DRAFT02 - Suivi des suggestions des analyses d'impact et des discussions dans la liste. - Support inclus pour ASN. - Inclus le 5.7.3.3 existant (renuméroté 5.7.2.3). - Indiquant quand inter-RIR les transferts sont activés. - S'assurer qu'il n'y a pas de déséquilibre ou d'opérations étranges dans les transferts une fois la proposition mise en œuvre. |
