Política pré-CPM

Ref. Nome AFPUB-2010-v4-003-draft-02
Status

Proposta Vencida

Data 24 2011 novembro
(S) autor Steve Bertrand
Chris Grundemann
Martin Hannigan
Aaron Hughes
Louie Lee
Matt Pounset
Jason Schiller
Política Afetada  
 
TOC

 

Incentivo:

Permitir todos IPv4 o estoque, independentemente do tamanho do prefixo, a ser devolvido e subsequentemente realocado de forma justa e equitativa pela IANA pós-saída.

 

1.) Justificativa

Esta política define o processo de alocação de IPv4 endereços pós "Fase de exaustão" [1]. Uma política global é necessária para que a IANA possa continuar a alocar de forma transparente IPv4 endereços além da exaustão. Para cumprir os requisitos desta política, a IANA deve estabelecer um pool de recuperação para manter e distribuir os endereços em conformidade com esta política. Esta política estabelece o processo pelo qual IPv4 os endereços podem ser devolvidos e reemitidos na fase pós-exaustão da IANA.

Este documento não estipula requisitos de desempenho na prestação de serviços pela IANA para um RIR de acordo com esta política. Tais requisitos devem ser especificados por acordos apropriados entre os RIRse ICANN.

 

O objetivo desta política é o seguinte:

    • Para incluir todas as fases pós-exaustão IPv4 espaço de endereço devolvido à IANA.
    • Permite alocações pela IANA do pool de recuperação uma vez que a fase de exaustão tenha sido concluída.
    • Define "necessidade" como base para mais IPv4 alocações pela IANA.
    • Não diferencia nenhuma classe de IPv4 espaço de endereço, a menos que definido de outra forma por um RFC.
    • Incentive o retorno de IPv4 espaço de endereço, tornando este processo de alocação disponível.
    • Proibir transferências de endereços provenientes do Pool de recuperação na ausência de um IPv4 Política de transferência global para neutralizar as desigualdades do processo de transferência entre RIR regiões.
    • Aplica-se ao legado IPv4 Espaço de endereçamento inicialmente alocado pela IANA aos usuários, incluindo as alocações para RIRs.
    • Inclui qualquer extensão de fragmentos atualmente em poder da IANA agora ou no futuro.



2.) Pool de recuperação

Após a adoção deste IPv4 política de endereço da Diretoria da ICANN, a IANA deve estabelecer um pool de recuperação a ser utilizado após RIR IPv4 exaustão, conforme definido na Seção 4. O pool de recuperação conterá inicialmente quaisquer fragmentos que possam ter sobrado no inventário da IANA. Assim que o primeiro RIR esgota seu estoque de espaço de endereço IP, este Pool de recuperação será declarado ativo. Quando o Pool de Recuperação é declarado ativo, a Política Global para a Alocação do Restante IPv4 Espaço de endereçamento [3] e política para alocação de IPv4 Os blocos para registros regionais da Internet [4] serão formalmente descontinuados.

 

3.) Devolução do espaço de endereçamento à IANA

A IANA aceitará no pool de recuperação todos os elegíveis IPv4 espaço de endereço oferecido para devolução. O espaço de endereçamento elegível inclui endereços que não são designados como "uso especial" por um RFC IETF ou endereços alocados para RIRa menos que estejam sendo devolvidos pelo RIR para os quais foram alocados originalmente. Os detentores de endereços legados podem devolver o espaço de endereços diretamente à IANA, se assim desejarem.

 

4.) Alocações de endereços do pool de recuperação pela IANA

As alocações do pool de recuperação podem começar assim que o pool for declarado ativo. Os endereços no Pool de recuperação devem ser alocados em um limite CIDR. As alocações do Pool de recuperação estão sujeitas a uma unidade de alocação mínima igual à unidade de alocação mínima de todos RIRse uma unidade de alocação máxima de um / 8. O pool de recuperação será dividido em limites CIDR e distribuído igualmente a todos os elegíveis RIRs uma vez a cada trimestre. Qualquer resto não divisível uniformemente pelo número de elegíveis RIRs permanecerão no pool de recuperação até que o retorno de endereço suficiente permita outra rodada de alocações.

 

5). RIR Elegibilidade para receber alocações do pool de recuperação

Após a exaustão de um RIRdo espaço livre da IANA e depois de receber seu / 8 final da IANA [3], um RIR se tornará elegível para solicitar espaço de endereçamento do pool de recuperação da IANA quando anunciar publicamente por meio de sua lista de anúncios globais de e-mail e postar um aviso em seu site informando que esgotou o estoque de IPv4 espaço de endereço. A exaustão é definida como um estoque inferior ao equivalente a um único / 8 e a incapacidade de atribuir espaço de endereço a seus clientes em unidades iguais ou menores do que o mais longo de qualquer RIRunidade de alocação mínima definida pela política da. Até um / 10 ou equivalente a IPv4 espaço de endereço especificamente reservado para qualquer propósito especial por um RIR não será contado contra isso RIR ao determinar a elegibilidade, a menos que esse espaço tenha sido recebido do pool de recuperação da IANA. Qualquer RIR que é formado depois que o Conselho de Diretores da ICANN ratificou esta política não é elegível para utilizar esta política para obter IPv4 espaço de endereço da IANA.

 

6.) Requisitos de relatórios

A IANA publicará pelo menos uma vez por semana um relatório que esteja disponível publicamente, detalhando, no mínimo, todo o espaço de endereçamento que foi recebido e alocado. A IANA publicará um relatório de espaço de endereço devolvido que indica quais recursos foram devolvidos, por quem e quando. A IANA deve publicar um relatório de alocações pelo menos uma vez por semana, que no mínimo indica o que IPv4 espaço de endereço foi alocado, que RIR recebeu a atribuição e quando. A IANA publicará um aviso público confirmando RIR elegibilidade subsequente à Seção 4.

 

7.) Sem direitos de transferência

O espaço de endereçamento atribuído do pool de recuperação pode ser transferido se houver uma política global ratificada pela diretoria da ICANN ou coordenada globalmente RIR política escrita especificamente para lidar com as transferências entreRIR ou de uma entidade para outra. As transferências devem atender aos requisitos de tal política. Na ausência de tal política, nenhuma transferência de qualquer tipo relacionada ao espaço de endereço alocado ou atribuído do pool de recuperação é permitida.

 

8.) Definições

IANA - Internet Assigned Numbers Authority, ou seu sucessor

ICANN - Internet Corporation for Assigned Names and Numbers, ou seu sucessor

RIR - Registro regional da Internet reconhecido pela ICANN

MoU - Memorando de Entendimento entre ICANN e o RIRs

IPv4 - Protocolo da Internet Versão Quatro (4), o protocolo alvo desta Política Global

Piscina Espaço Livre - IPv4 Endereços que estão em estoque em qualquer RIR, e / ou IANA

 

9) Colaboradores

As seguintes pessoas doaram seu tempo, recursos e esforços para desenvolver esta proposta em nome da comunidade da Internet:

Steve Bertrand
Chris Grundemann
Martin Hannigan
Aaron Hughes
Louie Lee
Matt Pounset
Jason Schiller

 


10) Referências

1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
Política global para a alocação dos restantes IPv4 Address Space, IANA, recuperado em 27 de abril de 2010

2. http://aso.icann.org/documents/memorandum-of-understanding/index.html MoU da Organização de Apoio a Endereços da ICANN (ASO), recuperado em 27 de maio de 2010.

3. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm Política global para a alocação dos restantes IPv4 Espaço de Endereço

4. http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf Política de Alocação de IPv4 Bloqueios para registros regionais da Internet

HISTÓRIA
25.08.2010 Proposta postada pela primeira vez na lista de discussão rpd por Steve Bertrand.
27.08.2010 Postado no site e referência atribuída AFPUB-2010-v4-003
25.11.2010 Nova atualização discutida durante AfriNIC-13 Public Policy Meeting e renomeada para AFPUB-2010-GEN-006
24.11.2011

 2011-11-24 - Proposta expira após um ano de inatividade.

Versão anterior
  AFPUB-2010-v4-003-draft-01

 

Adicionar ao carrinho

  • Ref. Nome: AFPUB-2014-GEN-004-DRAFT-03

  • Status: Última Chamada

  • Data: 03 de junho de 2015

  • Estado:
    Implementado
  • Autor (es):
    Frank Habicht, Tanzânia Internet Exchange,
    Michuki Mwangi, Sociedade da Internet / KIXP,
    Nishal Goburdhan, Casa de compensação de pacotes / JINX

 

1. Resumo do problema abordado por esta proposta

O AFRINIC possui uma política existente para fazer IPv4 atribuições à Infraestrutura Crítica, mas não uma para reservar especificamente espaço de Recursos de Número da Internet para IXPs. Como resultado, prevê-se que o esgotamento desses recursos possa dificultar, se não for impossível, que os IXPs obtenham recursos suficientes para crescer.

 

2. Resumo de como esta proposta aborda o problema 

Esta política solicita que o AFRINIC reserve e publique IPv4 recursos e ASNs para uso somente por IXPs. 

 

3. Proposta

3.1 Introdução

 

Considera-se amplamente que os Internet Exchange Points (IXPs) são um dos elementos críticos necessários para o desenvolvimento das economias da Internet. A África ainda está em processo de desenvolvê-las e, ao mesmo tempo, enfrenta o esgotamento iminente de suas IPv4 Recursos. 

 

Não tendo IPv4 endereços para aumentar ou iniciar novos IXPs criariam complexidade de roteamento desnecessária e desnecessária para redes conectadas à Internet, procurando espiar os IXPs para aprimorar seu escopo de rede.

 

AFRINIC já tem uma política existente para fazer alocações para IXPs [1], mas essa política não reserva especificamente IPV4 espaço para garantir que haverá tal, para os futuros IXPs crescerem e se desenvolverem. Além disso, esta política reserva um conjunto de ASNs entre 0 - 65535 para uso por IXPs, para IXP BGP Route Servers. 

 

3.2 Distinção entre peering IXP e redes de gerenciamento

 

Distinguimos entre dois tipos de recursos de números IP necessários e usados ​​nos IXPs. 

 

Uma LAN de pares IXP é o bloco de endereços de rede contíguo que o IXP usaria para atribuir endereços IP exclusivos a cada membro de pares, para cada participante de pares trocar tráfego de rede pela infraestrutura de pares compartilhada. A prática recomendada é que a rede local de IXP não esteja visível na visualização da tabela de roteamento global, entre outras coisas para reduzir os vetores de ataque dos roteadores de borda do ISP por meio do IXP. 

 

De uma perspectiva de identificação, monitoramento e análise de rede, é desejável, portanto, que o espaço da "LAN peering" seja fornecido a partir de um bloco contíguo. A LAN de gerenciamento IXP é a rede de gerenciamento que o IXP usa para fornecer serviços no IXP, como monitoramento, estatísticas, correio, sistemas de ticket, provisionamento de trânsito para raízes DNS, etc. Redes de gerenciamento devem ser alcançadas globalmente, por exemplo publicar dados e permitir acesso remoto à boa infraestrutura de rede comum (como servidores DNS raiz e TLD) e projetos de pesquisa. 

 

3.3 Uso de servidores de rota BGP 

 

Normalmente, os IXPs usam servidores de rota BGP para ajudar a gerenciar sessões de peering entre diferentes participantes. Os servidores de rota implementam a política de roteamento IXP na forma de comunidades BGP, normalmente na forma de A: B, onde A, B representam A = servidor de rota IXP BGP e B = participante ASN. 

 

As implementações atuais do BGP utilizam 6 bytes para o atributo de comunidade estendida. Portanto, um IXP com 4 bytes ASN em uso no servidor de rota não seria capaz de implementar com êxito o mapeamento da comunidade A: B BGP, se um participante do IXP tiver um byte de 4 bytes ASN. É provável que essa situação seja vivenciada por mais IXPs, como adicional de 4 bytes ASNs são alocados através do processo AFRINIC atual. 

 

Se as comunidades de servidores de rota IXP incluírem o IXP ASN e o par ASN (espera-se que seja de 4 bytes) e um total de apenas 6 bytes esteja disponível, segue que os servidores de rota IXP ASN não pode ter mais do que ocupar mais de 2 bytes. 

 

3.4 Proposta 

 

Para garantir que haja recursos suficientes para o desenvolvimento de IXPs, essa política propõe que a AFRINIC reserve IPv4 endereços para LANs emparelhando IXP a partir de um bloco de endereços marcado particularmente e exclusivamente para uso em LAN emparelhando IXP. 

 

As atribuições para LANs emparelhando IXP devem ser de um bloco dedicado, publicado como tal pela AFRINIC. As atribuições de LAN de peering para cada IXP devem garantir que o bloco / 24 IP adjacente seja reservado (com base no tamanho mínimo da política de atribuição de usuário final de / 24) para suportar o crescimento futuro do IXP. Isso permitirá que um IXP aumente seus recursos de LAN de pares para / 23 sem precisar renumerar para uma nova alocação de bloco IP contíguo. 

 

As atribuições para endereços de gerenciamento IXP NÃO devem ser fornecidas no mesmo bloco que as LANs emparelhamento IXP. 

 

Propõe-se que um bloco / 16 seja reservado para requisitos futuros para redes locais peering IXP na região de serviço do AFRINIC e que o AFRINIC publique esse bloco como tal. Além disso, as atribuições para a LAN de peering IXP devem reservar o bloco contíguo / 24 IP adjacente ao IXP solicitante para crescimento futuro.

 

Essas reservas serão mantidas até o momento em que o pool disponível do / 16 não possa mais alocar atribuições de / 23. Depois disso, novos pedidos podem ser atribuídos a partir do espaço reservado mantido para crescimento futuro de IXP. Propõe-se ainda reservar o equivalente a um bloco / 16 adicional para prefixos de gerenciamento IXP, separado das LANs de peering. 

 

Propõe-se que o AFRINIC reserve um bloco de ASNs entre 0 - 65535 para uso em servidores de rota BGP em IXPs na região de serviço do AFRINIC. O número de ASNs a serem reservados deve ser o maior de 114, ou metade do restante ASNs entre 0 - 65535 no bloco AFRINIC na data de ratificação desta política. A AFRINIC alocará esses recursos de acordo com a ordem de chegada. 

 

3.5 Critérios de avaliação 

 

Esta política não sugere novos critérios de avaliação para o que determina um IXP válido. 

 

4. Histórico de Revisões

  1. 23 Out 2014 - AFPUB-2014-GEN-004-DRAFT-01 publicado on rpd Lista.
  2. 05 de novembro de 2014 - AFPUB-2014-GEN-004-DRAFT-02 publicado no rpd Lista.
  3. 11 de junho de 2015 - AFPUB-2014-GEN-004-DRAFT-03 publicado on rpd Lista.

 


Referências

 

[1] Política AFRINIC para atribuições de usuários finais - AFPUB-2006-GEN-001, http://afrinic.net/en/library/policies/127-afpub-2006-gen-001 Seções (5) e (6)

 

 

Página 1 de 12