Plus de détails
|
Multihoming non requis pour ASN |
|||
|
ID: |
AFPUB-2019-ASN-001-DRAFT04 |
Date de soumission: |
25th Novembre 2019 |
|
Auteurs: |
Jordi Palet Martínez jordi.palet sur theipv6company.com The IPv6 Company |
Version: |
4.0 |
|
Statut: |
Mis en œuvre |
Modifie: |
Art CPM 7.0 |
Proposition
1. Résumé du problème traité par cette proposition
Quand le premier ASN la politique d'attribution a été conçue à l'origine, la principale préoccupation était que 16 bits est un espace d'adressage limité (RFC1930, section 9).
L'approche conservatrice de RFC1930, n'est plus un problème compte tenu des 32 bits ASN(RFC6793). Par exemple, si chacun des cinq RIRs devait attribuer 100 numéros AS par jour, 365 jours par an, il faudrait plus de 20,000 32 ans pour remplir l'espace XNUMX bits.
En outre, lors de la première ASN politiques ont été élaborées, la fiabilité des réseaux n’était pas aussi bonne qu’aujourd’hui et il était logique de s’assurer ASN titulaire à être «physiquement» multirésident.
Cependant, aujourd'hui, ce n'est pas nécessairement une exigence raisonnable, et même dans certains cas, certains réseaux peuvent nécessiter un ASN bien qu'ils ne soient pas disposés à être physiquement multi-hôtes (en raison du coût ou des emplacements distants qui n'ont qu'une seule liaison / en amont, etc.) et leurs exigences SLA n'ont pas besoin de cette redondance. Cependant, ils regardent avec différents AS (par exemple au moyen d'un IX), ce qui est également considéré comme un multihébergement.
De plus, dans certains cas, les fournisseurs en amont peuvent demander une ASN, ne pas en accepter un privé, et cela doit être une raison valable pour l'obtenir, car AFRINIC, ni la communauté n'a le moyen de forcer ces fournisseurs en amont à modifier leurs exigences, bien qu'ils se trompent. Ils prennent leurs propres décisions commerciales et opérationnelles.
Le déploiement de IPv6 a également accru la nécessité pour les organisations qui ne sont pas des FAI IPv6 PI afin d'avoir des adresses stables, et dans cette situation, idéalement, ils devraient annoncer leur espace PI avec leur propre ASN. Dans la plupart des cas, ils n'ont pas besoin d'être multi-logements.
La proposition indique toujours que les sites qui n'ont pas besoin d'unique ASNs, doivent utiliser des codes privés (64,512 65,535 - 4,200,000,000 4,294,967,294 et 1930 6996 XNUMX XNUMX - XNUMX XNUMX XNUMX XNUMX), conformément aux RFCXNUMX et RFCXNUMX, en référençant simplement les RFC pertinents, de sorte que la politique n'a pas besoin d'être mise à jour si l'IETF les met à jour.
2. Résumé de la façon dont cette proposition résout le problème
En plus de ranger le texte proprement dit, car il y a des répétitions dans la section 7 de la RPC (ASN), le texte proposé garantit que les organisations qui ont leur propre politique de routage et qui doivent s'interconnecter avec d'autres organisations peuvent effectivement le faire.
Le terme «interconnexion» est utilisé ici avec le sens commun d’établir une connexion entre deux réseaux (administrativement) distincts.
3. Proposition
Supprimer la section 7.1 actuelle et le paragraphe qui la précède, renuméroter toutes les autres et modifier la version 7.4 actuelle (éligibilité) comme suit.
|
Actuel |
Proposition |
|
7.0 ASN Cette section contient des politiques et des directives concernant la demande, l'attribution et l'enregistrement de numéros AS (Autonomous System) dans la région AFRINIC. 7.1 Présentation AFRINIC (l'African Network Information Center) est le registre Internet régional pour l'Afrique et une partie de la région de l'océan Indien (Seychelles, Maurice, Madagascar, Comores). Il est chargé de distribuer l'espace d'adressage Internet public et les ressources connexes (y compris les numéros de système autonome) dans la région et de coordonner l'élaboration et la mise en œuvre des politiques de gestion de ces ressources. Les politiques décrites dans ce document ont été développées par la communauté Internet grâce à un processus de consensus facilité par AFRINIC. Ils doivent être mis en œuvre par AFRINIC. 7.2 Portée Ce document décrit les politiques relatives à la distribution, la gestion et l'utilisation des numéros de système autonome (AS) dans la région de service AFRINIC. Ces politiques s'appliquent à IPv4 et IPv6 les réseaux. Les politiques d'autres régions autres que la région de service AFRINIC n'entrent pas dans le cadre de ce document.
7.3 Définitions … |
7.0 ASN Cette section contient les politiques relatives à la distribution, la gestion et l'utilisation des numéros de système autonome (AS) dans la région de service AFRINIC.
7.1 Définitions
[Conservez ici tout le texte du CPM 7.3 actuel] |
|
7.4 Admissibilité à l'attribution d'un numéro AS
Il est important de déterminer quels sites nécessitent des numéros AS uniques et ceux qui ne nécessitent pas de numéro AS unique doivent utiliser un ou plusieurs des numéros AS réservés à un usage privé. Ces numéros sont les suivants: 64512 à 65535 (RFC1930). Pour pouvoir prétendre à un numéro AS, l'organisation requérante doit remplir les conditions suivantes: 7.4.1 Une politique de routage unique (sa politique diffère de ses homologues de la passerelle frontalière). 7.4.2 Un site multi-hébergé. 7.4.3 Une organisation sera également éligible si elle peut démontrer qu'elle satisfera aux critères ci-dessus lorsqu'elle recevra ASN (ou dans un délai raisonnablement court par la suite). 7.4.4 Etre membre d'AFRINIC en règle (type utilisateur final ou LIR) Toutes les demandes de ASNs selon ces critères seront évalués en utilisant les lignes directrices décrites dans la RFC1930 «Lignes directrices pour la création, la sélection et l'enregistrement d'un système autonome (AS). |
7.2 Admissibilité à l'attribution d'un numéro AS
Il est important de déterminer quels sites nécessitent des numéros AS uniques. Les sites qui ne nécessitent pas de numéro AS unique doivent utiliser un ou plusieurs des numéros AS réservés à un usage privé (RFC1930, RFC6996). Afin de se qualifier pour un numéro AS, l'organisation requérante doit être un membre ressource AFRINIC et remplir l'une des conditions suivantes: 7.2.1 Interconnexion (y compris l'homologation) avec plus d'un AS. 7.2.2 Afficher une politique de routage unique ou démontrer un besoin technique pour une coordination mondiale unique ASN. Une organisation sera également éligible si elle peut démontrer qu'elle répondra aux critères ci-dessus lorsqu'elle recevra un ASN (ou dans les six mois suivants). |
4. Références
ARIN et LACNIC ne nécessitent pas de multihébergement. Un équivalent a soumis une proposition atteint un consensus dans APNIC47 et a déjà été mis en œuvre. RIPE l'exige, mais accepte le «peering» comme multihoming.
https://www.arin.net/policy/nrpm.html#five
https://www.lacnic.net/683/2/lacnic/
https://www.apnic.net/community/policy/proposals/prop-128
Changelog
4. Historique des révisions
|
Date |
Plus de détails |
|
27er Février 2019. |
Version 1 : AFPUB-2019-ASN-001-DRAFT01 Initiales Draft Publié sur rpd |
|
10 Avril 2019 |
Version 2 : AFPUB-2019-ASN-001-DRAFT02
|
|
3rd Novembre 2019 |
Version 3 : AFPUB-2019-ASN-001-DRAFT03
|
|
25th Novembre 2019 |
Version 4 : AFPUB-2019-ASN-001-DRAFT04
|
