Pré-CPM

Réf. Nom AFPUB-2010-v4-003-draft- 02
Statut

Proposition expirée

Date 24 novembre 2011
Auteurs) Steve Bertrand
Chris Grundmann
Martin Hannigan
Aaron Hugues
Louis Lee
Matt Pounset
Jason Schiller
Politique affectée  
 
TOC

 

Motivation:

Autorise tout IPv4 l'inventaire, quelle que soit la taille du préfixe, à renvoyer, puis réaffecté de manière juste et équitable par l'IANA après la fin de l'exécution.

 

1.) Justification

Cette politique définit le processus d'allocation des IPv4 adresses post "Phase d'épuisement" [1]. Une politique globale est requise pour que l'IANA puisse continuer de manière transparente à être en mesure d'allouer IPv4 aborde au-delà de l'épuisement. Afin de satisfaire aux exigences de cette politique, l'IANA doit mettre en place un pool de récupération pour conserver les adresses et distribuer conformément à cette politique. Cette politique établit le processus par lequel IPv4 les adresses peuvent être retournées et réémises à partir de la phase IANA post-épuisement.

Ce document ne stipule pas d'exigences de performance dans la fourniture de services par l'IANA à un RIR conformément à cette politique. Ces exigences devraient être spécifiées par des accords appropriés entre les RIRs et ICANN.

 

L'intention de cette politique est la suivante:

    • Pour inclure toutes les phases post-épuisement IPv4 espace d'adressage retourné à l'IANA.
    • Permet des allocations par l'IANA à partir du pool de récupération une fois la phase d'épuisement terminée.
    • Définit le «besoin» comme base pour IPv4 allocations de l'IANA.
    • Ne différencie aucune classe de IPv4 l'espace d'adressage, sauf indication contraire par un RFC.
    • Encourager le retour de IPv4 l'espace d'adressage en rendant ce processus d'allocation disponible.
    • Interdire les transferts d'adresses provenant du pool de récupération en l'absence d'un IPv4 Politique de transfert mondiale pour neutraliser les inégalités de processus de transfert entre RIR les régions.
    • S'applique à l'héritage IPv4 Espace d'adressage initialement alloué par l'IANA aux utilisateurs, y compris les allocations à RIRs.
    • Comprend toute longueur de fragments actuellement détenus par l'IANA maintenant ou à l'avenir.



2.) Bassin de remise en état

Lors de l'adoption de cette IPv4 adresse politique du Conseil d'administration de l'ICANN, l'IANA établira un pool de récupération à utiliser après RIR IPv4 l'épuisement tel que défini dans la section 4. Le pool de récupération contiendra initialement tous les fragments qui pourraient être laissés dans l'inventaire IANA. Dès le premier RIR épuise son inventaire d'espace d'adressage IP, ce pool de récupération sera déclaré actif. Lorsque le pool de récupération est déclaré actif, la politique globale d’allocation du solde IPv4 Espace d'adressage [3] et politique d'attribution des IPv4 Les blocs des registres Internet régionaux [4] seront officiellement obsolètes.

 

3.) Retour de l'espace d'adressage à l'IANA

L'IANA acceptera dans le pool de récupération tous les éligibles IPv4 espace d'adressage qui sont proposés pour le retour. L'espace d'adressage éligible comprend les adresses qui ne sont pas désignées comme «à usage spécial» par un RFC IETF ou les adresses attribuées à RIRsauf s'ils sont retournés par le RIR auquel ils ont été attribués à l'origine. Les détenteurs d'adresse hérités peuvent retourner l'espace d'adressage directement à l'IANA s'ils le souhaitent.

 

4.) Allocations d'adresses du pool de récupération par l'IANA

Les allocations du pool de récupération peuvent commencer une fois que le pool est déclaré actif. Les adresses dans le pool de récupération doivent être allouées sur une limite CIDR. Les allocations du pool de remise en état sont soumises à une unité d'allocation minimale égale à l'unité d'allocation minimale de tous RIRs et une unité d'allocation maximale de 8/XNUMX. Le bassin de remise en état sera divisé aux limites du CIDR et réparti également entre tous les RIRs une fois par trimestre. Tout reste non également divisible par le nombre d’éligibles RIRLes s resteront dans le pool de récupération jusqu'à ce que des retours d'adresse suffisants permettent une autre ronde d'allocations.

 

5.) RIR Admissibilité à recevoir des allocations du bassin de remise en état

À l'épuisement d'un RIRespace libre et après avoir reçu leur finale / 8 de l'IANA [3], un RIR deviendra éligible pour demander un espace d'adressage au pool de régénération de l'IANA lorsqu'elle annoncera publiquement via sa liste de diffusion d'annonces mondiales respective et en publiant un avis sur son site Web indiquant qu'elle a épuisé sa réserve de IPv4 espace d'adressage. L'épuisement est défini comme un inventaire inférieur à l'équivalent d'un single / 8 et l'incapacité d'attribuer davantage d'espace d'adressage à ses clients en unités égales ou plus courtes que la plus longue de toutes RIRUnité d'allocation minimale définie par la politique. Jusqu'à 10/XNUMX ou équivalent de IPv4 espace d’adresse spécifiquement réservé à un usage spécial par un RIR ne sera pas compté contre cela RIR lors de la détermination de l'éligibilité, sauf si cet espace a été reçu du pool de récupération IANA. Tout RIR qui est formé après que le conseil d'administration de l'ICANN a ratifié cette politique n'est pas autorisé à utiliser cette politique pour obtenir IPv4 l'espace d'adressage de l'IANA.

 

6.) Exigences de déclaration

L'IANA publiera au moins une fois par semaine un rapport accessible au public qui détaille au minimum tout l'espace d'adressage reçu et alloué. L'IANA publiera un rapport sur l'espace d'adressage renvoyé qui indique quelles ressources ont été retournées, par qui et quand. L'IANA publiera un rapport d'allocations au moins une fois par semaine qui indique au minimum ce que IPv4 un espace d'adressage a été alloué, ce qui RIR reçu l'allocation et quand. L'IANA publiera un avis public confirmant RIR éligibilité postérieure à la section 4.

 

7.) Aucun droit de transfert

L'espace d'adresse attribué à partir du pool de récupération peut être transféré s'il existe une politique mondiale ratifiée par le conseil d'administration de l'ICANN ou coordonnée au niveau mondial RIR spécifiquement écrite pour traiter les transferts, qu’ils soient inter-RIR ou d'une entité à une autre. Les transferts doivent répondre aux exigences d'une telle politique. En l'absence d'une telle politique, aucun transfert d'aucune sorte lié à l'espace d'adressage alloué ou attribué à partir du pool de récupération n'est autorisé.

 

8.) Définitions

IANA - Internet Assigned Numbers Authority, ou son successeur

ICANN - Internet Corporation for Assigned Names and Numbers, ou son successeur

RIR - Registre Internet régional reconnu par l'ICANN

MoU - Protocole d'accord entre l'ICANN et le RIRs

IPv4 - Protocole Internet version quatre (4), le protocole cible de cette politique globale

Piscine d'espace libre - IPv4 Adresses en inventaire à tout moment RIRet / ou l'IANA

 

9) Contributeurs

Les personnes suivantes ont donné de leur temps, de leurs ressources et de leurs efforts pour développer cette proposition au nom de la communauté Internet:

Steve Bertrand
Chris Grundmann
Martin Hannigan
Aaron Hugues
Louis Lee
Matt Pounset
Jason Schiller

 


10) Références

1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
Politique globale pour l'allocation du solde IPv4 Espace d'adressage, IANA, récupéré le 27 avril 2010

2. http://aso.icann.org/documents/memorandum-of-understanding/index.html ICANN Address Supporting Organization (ASO) MoU, récupéré le 27 mai 2010.

3. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm Politique globale pour l'allocation du solde IPv4 Espace d'adressage

4. http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf Politique d'attribution des IPv4 Blocs aux registres Internet régionaux

Notre Histoire
25.08.2010 Proposition publiée pour la première fois sur la liste de diffusion rpd par Steve Bertrand.
27.08.2010 Publié sur le site Web et attribué la référence AFPUB-2010-v4-003
25.11.2010 Nouvelle mise à jour discutée lors de la réunion de politique publique d'AfriNIC-13 et renommée AFPUB-2010-GEN-006
24.11.2011

 2011-11-24 - La proposition expire après un an d'inactivité.

La version précédente
  AFPUB-2010-v4-003-draft- 01

 

Détails

  • Réf. Nom: AFPUB-2014-GEN-004-DRAFT- 03

  • Statut : dernier appel

  • Date: 03 juin 2015

  • Statut:
    Mis en œuvre
  • Auteurs):
    Franck Habicht, Tanzanie Internet Exchange,
    Michuki Mwangi, Internet Society / KIXP,
    Nishal Goburdhan, Centre d'échange de paquets / JINX

 

1. Résumé du problème traité par cette proposition

AFRINIC a une politique existante pour faire IPv4 des affectations à l'infrastructure critique, mais pas une pour réserver spécifiquement un espace Internet Number Resources pour les IXP. En conséquence, il est prévu que l'épuisement de ces ressources pourrait rendre difficile, voire impossible, pour les IXP d'obtenir des ressources suffisantes pour croître.

 

2. Résumé de la manière dont cette proposition résout le problème 

Cette politique demande à AFRINIC de réserver et de publier IPv4 les ressources, et ASNs à l'usage des IXP uniquement. 

 

3. Proposition

3.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 dispose déjà d'une politique existante pour effectuer des allocations aux IXP [1], mais cette politique ne réserve pas spécifiquement d'espace IPV4 pour garantir qu'il y en aura, pour que les futurs IXP puissent croître et se développer. 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. 

 

3.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. 

 

3.3 Utilisation des serveurs de route BGP 

 

Les IXP utilisent généralement 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. 

 

3.4 Proposition 

 

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. 

 

3.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. 

 

4. Historique des révisions

  1. 23 oct. 2014 - AFPUB-2014-GEN-004-DRAFT- 01 posté on rpd liste.
  2. 05 nov. 2014 - AFPUB-2014-GEN-004-DRAFT- 02 Posté sur rpd liste.
  3. 11 juin 2015 - AFPUB-2014-GEN-004-DRAFT- 03 posté on rpd liste.

 


Références

 

[1] Politique AFRINIC pour les attributions d'utilisateurs finaux - AFPUB-2006-GEN-001, http://afrinic.net/en/library/policies/127-afpub-2006-gen-001 Sections (5) et (6)

 

 

Page 1 de 12