Proposition
1.0 Résumé du problème traité par cette proposition
Par une proposition de politique “IPv6 PI Update ”(AFPUB-2018-V6-004), la Politique d'espace IPv6 indépendant du fournisseur (PI) qui fournit l'espace IPv6 pour les sites finaux a été révisé / mis à jour.
Cette révision a cependant ignoré une phrase de la section précédente 6.8.2.v, qui se lisait comme suit:
«Le« site final »doit montrer un plan d'utilisation et annoncer l'espace d'adressage IPv6 indépendant du fournisseur dans les douze (12) mois. Passé ce délai, s'il n'est pas annoncé, l'espace d'adressage IPv6 PI doit être récupéré et retourné au pool gratuit par AFRINIC ».
Ce texte a été conservé sous 6.8.2.iv.
Bien sûr, cela n'a pas de sens car il y a plusieurs cas possibles, qui sont dans le cadre de cette politique, qui n'annonceront pas leur IPv6 Espace d'adressage PI, tel que:
- Espace de peering LAN d'IXP.
- La numérotation des réseaux privés non connectés à Internet est un cas d'utilisation parfaitement valable pour l'Espace IPv6 PI et doit être pris en charge par la politique du RIR.
En outre, le texte existant fait référence aux sites finaux, alors qu'il devrait en fait considérer les organisations d'utilisateurs finaux. Un site final, considéré comme un «emplacement» unique, ne traitera pas des cas tels que les organisations ayant plusieurs sites finaux et forcera plusieurs adhésions d'utilisateurs finaux AFRINIC.
Une organisation avec plusieurs end-sites tombera probablement dans l'un des cas suivants:
- Plusieurs end sites connectés avec la couche 2 et BGP à leurs amonts (une banque, une université multi-campus, etc.), pourront obtenir une longueur de préfixe suffisante pour accueillir le nombre total de sites, espérons-le dans la limite de grignotage et annoncer un seul préfixe agrégé.
- Plusieurs end sites non connectés entre eux et annoncés comme des réseaux "différents", par exemple, même avec différents FAI. Typiquement, utilisera et annoncera un single / 48 pour chaque site final.
- Un cas de mélange possible parmi 1 et 2 ci-dessus.
2.0 Résumé de la façon dont cette proposition résout le problème
Reformulation simple du texte pour permettre aux cas qui n'ont pas besoin d'annoncer leur Espace IPv6 PI.
Proposition 3.0
|
Actuel
|
Proposition
|
|
6.8 Affectations PI
Cette politique vise à fournir l'espace d'adressage IPv6 aux sites finaux.
|
6.8 Affectations PI
Cette politique vise à fournir l'espace d'adressage IPv6 aux sites finaux.
|
|
6.8.1 Introduction
Cette politique permet d'attribuer des «sites finaux» IPv6 adresses indépendantes du fournisseur (PI). Les «sites finaux» comprennent les utilisateurs finaux et les fournisseurs d'infrastructures critiques tels que les opérateurs de serveurs racine TLD et les points d'échange Internet publics (IXP).
|
6.8.1 Introduction
Cette politique permet l'attribution des adresses IPv6 PI aux sites finaux qui détiennent et qui réunissent les
fournisseurs d'infrastructures critiques tels que les serveurs
racine, les domaines de premier niveau (TLD) et les points d'échange Internet publics (IXP).
|
|
6.8.2 Critères d'attribution
- Cible d'affectation - Sites finaux qui fournissent des services Internet publics pour un seul réseau d'organisations administratives, quelle que soit leur taille.
- Critères d'affectation:
- Le site final ne doit pas être un LIR
- Le site final doit devenir un membre utilisateur final AFRINIC et payer les frais AFRINIC normaux pour sa catégorie d'adhésion.
- Le site final doit justifier la nécessité de la IPv6 Espace d'adressage PI.
- Le site final doit montrer un plan d'utilisation de l' espace d'adressage IPv6 indépendant du fournisseur dans les douze (12) mois. Passé ce délai, s'il n'est pas annoncé, l'espace d'adressage IPv6 PI doit être récupéré et renvoyé au pool gratuit par AFRINIC.
- L'espace d'adressage IPv6 indépendant du fournisseur qui doit être annoncé par le site final ne doit pas être ventilé.
|
6.8.2 Critères d'attribution
- Cible d'affectation - Organisations d'utilisateurs finaux qui fournissent des services pour le réseau de leurs organisations administratives, quelle que soit leur taille.
- Critères d'affectation:
- L'organisation ne doit pas être une LIR.
- L'organisation doit être ou devenir membre utilisateur final d'AFRINIC.
- Le site final doit justifier le besoin d'espace d'adressage IPv6 PI.
- L'organisation doit déployer un espace d'adressage IPv6 indépendant du fournisseur sur chacun des sites finaux pour lesquels des adresses sont obtenues, dans un délai de douze (12) mois.
- Si l'espace d'adressage émis en vertu de cette politique doit être annoncé, dans la mesure du possible, l'organisation doit regrouper toutes les annonces de préfixes afin de minimiser l'effet sur la croissance de la table de routage globale.
|
|
6.8.3 Espace d'adressage indépendant du fournisseur (PI):
- L'affectation indépendante du fournisseur (PI) doit être effectuée à partir d'un bloc spécifique.
- La taille d'affectation indépendante du fournisseur initial à un site d'extrémité doit être de / 48, ou un préfixe plus court si le site d'extrémité peut le justifier.
- Les attributions suivantes doivent être documentées et justifiées. Dans la mesure du possible, ces attributions seront effectuées à partir d'un bloc d'adresses contigu (c'est-à-dire en étendant les bits "n" d'affectation existants vers la gauche).
|
6.8.3 Espace d'adressage indépendant du fournisseur (PI):
- L'affectation indépendante du fournisseur (PI) doit être effectuée à partir d'un bloc spécifique.
- La taille d'affectation indépendante du fournisseur initial pour chaque organisation doit être d'au moins / 48 par site final. Si plusieurs sites d'extrémité sont demandés et seront connectés les uns aux autres, un préfixe aligné sur le quartet sera émis suffisamment pour autoriser au moins un / 48 par site final. Une justification valable pour un préfixe plus court pour tous les sites d'extrémité doit être prise en compte.
- L'attribution de l'organisation sera calculée sur la base du nombre de sites d'extrémité et ajustée à la limite de quartet la plus proche.
- Les attributions suivantes doivent être documentées et justifiées. Dans la mesure du possible, ces attributions seront effectuées à partir d'un bloc d'adresses contigu (c'est-à-dire en étendant les bits "n" d'affectation existants vers la gauche).
- AFRINIC utilisera un algorithme d'allocation étendu lors de l'émission d'espace pour maximiser les chances de succès du mécanisme défini au paragraphe précédent.
|
|
6.8.4 Rectifier la taille d'une affectation initiale
- Un site final peut soumettre un nouveau plan d'adressage à AFRINIC si le plan initialement soumis pour justifier la mission initiale ne répond plus à leurs besoins actuels.
- La nouvelle affectation sera conforme au nouveau plan et sera conforme aux 6.8.2 et 6.8.3.
- Si possible, le même bloc d'adresse sera «mis à niveau» à la nouvelle taille de préfixe requise. Cependant, si les préfixes adjacents sont déjà utilisés par d'autres organisations ou si une telle affectation ne laisse pas suffisamment d'espace pour des affectations ultérieures, AFRINIC informera l'organisation requérante, qui aura les options suivantes:
je. Recevoir un nouveau bloc avec la nouvelle taille de préfixe demandée, avec l'engagement de renuméroter son réseau et de retourner le bloc d'origine dans un délai de 6 mois;
ii. Recevez un nouveau bloc qui, avec le bloc déjà attribué, couvre le nouveau besoin justifié et conservez les deux blocs.
Cette procédure ne peut être utilisée qu'une seule fois par chaque site d'extrémité.
|
6.8.4 Rectifier la taille d'une affectation initiale
- Une organisation peut soumettre un nouveau plan d'adressage à AFRINIC si le plan initialement soumis pour justifier la mission initiale ne répond plus à ses besoins actuels.
- La nouvelle affectation sera conforme au nouveau plan et sera conforme aux 6.8.2 et 6.8.3.
- Si possible, le même bloc d'adresse sera «mis à niveau» à la nouvelle taille de préfixe requise. Cependant, si les préfixes adjacents sont déjà utilisés par d'autres organisations ou si une telle affectation ne laisse pas suffisamment d'espace pour des affectations ultérieures, AFRINIC informera l'organisation requérante, qui aura les options suivantes:
je. Recevez un nouveau bloc avec la nouvelle taille de préfixe demandée, avec l'accord d'utiliser le nouveau bloc pour tous les déploiements futurs et de déprécier l'ancien bloc par attrition, retournant lorsqu'il est vide. Il n'y a pas de date limite de retour pour le moment;
ii. Recevez un nouveau bloc qui, avec le bloc déjà attribué, couvre le nouveau besoin justifié et conservez les deux blocs.
Cette procédure ne peut être utilisée qu'une seule fois par chaque organisation.
|
4. Références
D'autres RIRs ont déjà intégré cette exigence dans leurs politiques:
- APNIC: 10.1.4. Indépendant du fournisseur IPv6 affectation
https://www.apnic.net/community/policy/resources#Part%203:%20IPv6%20Policy
- ARIN: 6.5.8.1. Critères d'affectation initiale
https://www.arin.net/participate/policy/nrpm/#6-5-8-direct-assignments-from-arin-to-end-user-organizations
- LACNIC: 4.5.4.2 Affectation directe du portable IPv6 adresses vers des sites finaux n'ayant pas de portable IPv4 adresses précédemment attribuées par LACNIC
https://www.lacnic.net/684/2/lacnic/4-ipv6-address-allocation-and-assignment-policies
- MÛRE: 7. IPv6 Affectations indépendantes du fournisseur (PI)
https://www.ripe.net/publications/docs/ripe-707#IPv6_PI_Assignments
