Detalhes
Multihoming não é necessário para ASN |
|||
IDENTIDADE: |
AFPUB-2019-ASN-001-DRAFT04 |
Data Enviada: |
25th Novembro de 2019 |
autores: |
Jordi Palet Martinez jordi.palet em theipv6company.com O IPv6 Sobre |
Versão: |
4.0 |
Estado: |
Implementado |
Altera: |
CPM arte 7.0 |
Proposta
1. Resumo do problema tratado nesta proposta
Quando o primeiro ASN A política de atribuição foi originalmente projetada, a principal preocupação era que 16 bits é um espaço de endereço limitado (RFC1930, seção 9).
A abordagem conservadora da RFC1930 não é mais um problema, considerando os 32 bits ASNde (RFC6793). Por exemplo, se cada um dos cinco RIRs deviam atribuir 100 números AS por dia, 365 dias por ano, levaria mais de 20,000 anos para preencher o espaço de 32 bits.
Além disso, quando inicial ASN políticas foram desenvolvidas, a confiabilidade das redes não era tão boa quanto hoje e fazia sentido ter certeza de uma ASN titular a ser "fisicamente" multihomed.
No entanto, hoje isso não é necessariamente um requisito razoável e, mesmo em alguns casos, algumas redes podem exigir um ASN embora não esteja disposto a ser fisicamente multihomed (devido ao custo ou locais remotos que têm apenas um único link / upstream, etc.) e seus requisitos de SLA não precisam dessa redundância. No entanto, eles estão fazendo peering com diferentes ASs (por exemplo, por meio de um IX), que normalmente também é considerado multihoming.
Além disso, em alguns casos, os provedores upstream podem solicitar um ASN, não aceitando um privado, e este deve ser um motivo válido como justificativa para obtê-lo, porque AFRINIC, nem a comunidade tem como forçar esses prestadores a montante a alterar seus requisitos, apesar de estar errado. Eles tomam suas próprias decisões comerciais e operacionais.
A implantação de IPv6 também aumentou a necessidade de organizações que não são ISPs para obter IPv6 PI para ter endereços estáveis e, nessa situação, idealmente, eles devem anunciar seu espaço de PI com o seu próprio ASN. Na maioria dos casos, eles não precisam ser multihomed.
A proposta ainda indica que os sites que não precisam de exclusividade ASNs, deve usar os privados (64,512 - 65,535 e 4,200,000,000 - 4,294,967,294), de acordo com RFC1930 e RFC6996, apenas referenciando os RFCs relevantes, de modo que a política não precise ser atualizada se a IETF os atualizar.
2. Resumo de como esta proposta aborda o problema
Além de arrumar o próprio texto, pois existem algumas repetições na Seção 7 do CPM (ASN), o texto proposto garante que as organizações que têm sua própria política de roteamento e precisam se interconectar com outras organizações possam realmente fazer isso.
“Interconexão” é usado aqui com o significado comumente compreendido de estabelecer uma conexão entre duas redes separadas (administrativamente).
3. Proposta
Excluir a seção 7.1 atual e o parágrafo anterior, renumerar todas as outras e alterar a seção 7.4 (Elegibilidade) atual, como segue.
Atual |
Proposto |
7.0 ASN Esta seção contém políticas e diretrizes relativas à solicitação, atribuição e registro de números AS (Sistema Autônomo) na região AFRINIC. 7.1. Introdução O AFRINIC (Centro Africano de Informações de Rede) é o registro regional da Internet para a África e parte da região do Oceano Índico (Seychelles, Maurício, Madagascar, Comores). É responsável por distribuir o espaço público de endereço da Internet e recursos relacionados (incluindo números de sistemas autônomos) na região e coordenar o desenvolvimento e a implementação das políticas para gerenciar esses recursos. As políticas descritas neste documento foram desenvolvidas pela comunidade da Internet através de um processo de consenso facilitado pelo AFRINIC. Eles devem ser implementados pelo AFRINIC. 7.2 Escopo Este documento descreve as políticas relacionadas à distribuição, gerenciamento e uso de números do Sistema Autônomo (AS) na região de serviço do AFRINIC. Essas políticas se aplicam a IPv4 e IPv6 redes. Políticas de outras regiões que não sejam a região de serviço AFRINIC estão fora do escopo deste documento.
7.3 Definições ... |
7.0 ASN Esta seção contém as políticas relacionadas à distribuição, gerenciamento e uso de números do Sistema Autônomo (AS) na região de serviço do AFRINIC.
7.1 Definições
[Retenha aqui todo o texto do CPM 7.3 atual] |
7.4 Elegibilidade para uma atribuição de número AS
É importante determinar quais sites exigem números de AS exclusivos e quais não exigem um número de AS exclusivo, que devem usar um ou mais números de AS reservados para uso privado. Esses números são: 64512 a 65535 (RFC1930). Para se qualificar para um número AS, a organização solicitante deve atender aos seguintes requisitos: 7.4.1 Uma política de roteamento exclusiva (sua política difere dos pares de gateway de fronteira). 7.4.2 Um site com hospedagem múltipla. 7.4.3 Uma organização também será elegível se puder demonstrar que cumprirá os critérios acima ao receber um ASN (ou dentro de um período razoavelmente curto a partir de então). 7.4.4 Ser um membro AFRINIC em situação regular (usuário final ou tipo LIR) Todos os pedidos de ASNs sob esses critérios serão avaliados usando as diretrizes descritas na RFC1930 "Diretrizes para a criação, seleção e registro de um Sistema Autônomo (AS). |
7.2 Elegibilidade para uma atribuição de número AS
É importante determinar quais sites exigem números AS exclusivos. Os sites que não exigem um número AS exclusivo devem usar um ou mais números AS reservados para uso privado (RFC1930, RFC6996). Para se qualificar para um número AS, a organização solicitante deve ser um membro de recursos AFRINIC e cumprir qualquer um dos seguintes requisitos: 7.2.1 Interconecte (incluindo emparelhamento) com mais de um AS. 7.2.2 Mostre uma política de roteamento exclusiva ou demonstre uma necessidade técnica de um serviço global coordenado exclusivo ASN. Uma organização também será elegível se puder demonstrar que atenderá aos critérios acima ao receber um ASN (ou dentro dos seis meses seguintes). |
4. Referências
ARIN e LACNIC não requerem multihoming. Um equivalente proposta alcançou consenso no APNIC47 e já foi implementado. RIPE exige, mas aceita “peering” como 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. Histórico de Revisões
Data |
Detalhes |
27 de fevereiro de 2019 |
Versão 1: AFPUB-2019-ASN-001-DRAFT01 Inicie Draft Postado em rpd |
10 de Abril de 2019 |
Versão 2: AFPUB-2019-ASN-001-DRAFT02
|
3rd Novembro de 2019 |
Versão 3: AFPUB-2019-ASN-001-DRAFT03
|
25th Novembro de 2019 |
Versão 4: AFPUB-2019-ASN-001-DRAFT04
|