Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

Manual consolidado de políticas (v1.4)

Imprimir amigável, PDF e e-mail

Esta versão CPM foi substituída por esta versão CPM

 

 

1.0 Introdução

As políticas para gerenciar recursos de número IP na região de serviço do AFRINIC são criadas por meio de um PDP (Policy Development Process) que descreve as etapas pelas quais as propostas de política são enviadas, consideradas, debatidas (pela comunidade) e adotadas (pela AFRINIC). Este documento contém políticas ratificadas e implementadas que passaram pelo PDP.

O AFRINIC é uma organização independente sem fins lucrativos que atua como um dos cinco registros regionais da Internet (RIRs) Sua região de serviço incorpora o continente africano e parte do Oceano Índico (Seychelles, Maurício, Madagascar, Comores e Reunião).  

2.0  Definições Gerais

Os termos a seguir e suas definições são de particular importância para a compreensão das metas, ambiente e políticas descritas neste documento.


2.1 Registro da Internet (IR)

Um Registro da Internet (IR) é uma organização responsável pela distribuição do espaço de endereço IP para seus clientes e pelo registro desses endereços. Os IRs são classificados de acordo com sua função principal e escopo territorial dentro da estrutura hierárquica.


2.2 Registro regional da Internet (RIR)

Registros regionais da Internet anteriores (RIRs) foram estabelecidos sob a autoridade e iniciativas das comunidades da Internet em suas respectivas regiões. Atualmente, a ICANN autoriza o estabelecimento de RIRs para servir e representar grandes regiões geográficas. O papel principal de RIRs é gerenciar e distribuir o espaço público de endereços da Internet em suas respectivas regiões.

Atualmente, existem cinco RIRs: APNICARIN, LACNICRIPE NCC e AFRINIC.


2.3 Registro de Internet Local (LIR)

Um Local Internet Registry (LIR) é um IR que recebe alocações de um RIR e atribui principalmente espaço de endereçamento a 'usuários finais'. LIRs são geralmente ISPs. Seus clientes são outros ISPs e possivelmente usuários finais. Os LIRs devem ser membros do AFRINIC.


2.4 Alocação

"Alocar" significa distribuir espaço de endereço para LIRs para fins de distribuição subsequente.


2.5 Subalocação

"Subalocar" significa distribuir espaço de endereço (por LIRs) aos ISPs para fins de distribuição subsequente.


2.6 Atribuição

Uma atribuição é um bloco de endereço IP fornecido por um LIR a seus usuários finais para uso próprio. "Atribuir" significa delegar espaço de endereçamento a um ISP ou Usuário Final para uso específico na infraestrutura da Internet em que operam. As atribuições devem ser feitas apenas para fins específicos documentados por organizações específicas e não devem ser sub-atribuídas a outras partes.


2.7 Espaço IP PA (Agregável do Provedor)

O espaço do PA é o que foi alocado aos LIRs a partir dos quais eles podem atribuir ou subalocar para usuários finais / redes downstream como um bloco não portátil. Se a rede do usuário final / downstream mudar de provedor, o espaço de endereço atribuído ou subalocado pelo LIR (provedor de serviços anterior) deve ser retornado e a rede renumerada.


2.8 Espaço IP PI (independente do provedor)

O espaço PI (ou portátil) não pode ser agregado e pode ser atribuído apenas por RIR através de um LIR. O espaço do PI é caro para rotear e pode não ser globalmente roteável. As subalocações não podem ser feitas a partir deste tipo de espaço de endereço pelo usuário final ou LIR.

3.0  O Processo de Desenvolvimento de Políticas (PDP)

Esta seção descreve o processo de desenvolvimento de políticas da AFRINIC (PDP). As políticas são decisões documentadas da comunidade AFRINIC que determinam diretamente as regras pelas quais o AFRINIC gerencia e administra os recursos numéricos da Internet.

Os procedimentos descritos neste documento foram projetados para serem justos, abertos e objetivos e visam:

uma. Oferecer ampla oportunidade para participação e comentários de todas as partes interessadas;

b. Estabeleça amplo consenso na comunidade da Internet.

Esses procedimentos adotam práticas geralmente aceitas e oferecem flexibilidade para se adaptar a uma variedade de circunstâncias que podem ocorrer em um processo.


3.1  Escopo do PDP

O Processo de Desenvolvimento de Políticas abrange o desenvolvimento e a modificação de políticas para lidar com os Recursos de Número da Internet na região de serviços do AFRINIC. Alterações no próprio processo de desenvolvimento de políticas também seguirão o processo.

As políticas de recursos de números da Internet são distintas das práticas e procedimentos gerais de negócios da AFRINIC. As práticas e procedimentos gerais de negócios não estão dentro do alcance do Processo de Desenvolvimento de Políticas. 


3.2  Princípios de Desenvolvimento de Políticas

Todas as políticas são desenvolvidas pela comunidade da Internet seguindo os três princípios de abertura, transparência e justiça. A comunidade da Internet inicia e discute as propostas. Se o consenso for alcançado no draft política, é recomendada ao Conselho de Administração da AFRINIC para adoção como uma política.

3.2.1 Abertura

Todas as políticas são desenvolvidas em um fórum aberto no qual qualquer um pode participar. Não há qualificações para participação.

3.2.2 Transparência

Todos os aspectos do processo de desenvolvimento de políticas estão documentados e disponíveis ao público no site da AFRINIC. As discussões são arquivadas publicamente. Todos os procedimentos desenvolvidos para implementar a política são documentados pela AFRINIC e estão disponíveis ao público.

3.2.3 Justiça

As políticas são para garantir uma distribuição justa de recursos e facilitar o funcionamento da Internet. As ações são realizadas dentro de um período de tempo razoável.


3.3  Grupo de Trabalho para Desenvolvimento de Políticas (PDWG)

O Grupo de Trabalho para Desenvolvimento de Políticas (PDWG) discute as propostas. Qualquer pessoa pode participar via Internet ou pessoalmente. O trabalho do PDWG é realizado na lista de discussão Discussão sobre política de recursos (Este endereço de e-mail está protegido contra spambots. Você deve habilitar o JavaScript para visualizá-lo.) e as reuniões semestrais da AFRINIC Public Policy (PPM). Qualquer pessoa, participando pessoalmente ou remotamente, é considerada parte do Grupo de Trabalho para Desenvolvimento de Políticas.

O Grupo de Trabalho para o Desenvolvimento de Políticas possui dois presidentes para desempenhar suas funções administrativas. Os presidentes do PDWG são escolhidos pela comunidade AFRINIC durante a Reunião de Políticas Públicas e cumprem mandatos escalonados de dois anos. O mandato termina durante a primeira Reunião de Política Pública correspondente ao final do mandato para o qual foram nomeados. Um mandato pode começar ou terminar antes do primeiro dia da Reunião de Políticas Públicas e até o último dia da Reunião de Políticas Públicas, conforme determinado pelo acordo mútuo do atual Presidente e do novo Presidente.

Se o presidente do grupo de trabalho não puder cumprir seu mandato completo, o grupo de trabalho poderá selecionar um substituto para servir o restante do mandato. Se os presidentes dos grupos de trabalho não puderem comparecer à reunião pública de políticas, o grupo de trabalho nomeará um presidente para a sessão. Qualquer pessoa presente à reunião, seja pessoalmente ou por participação remota, pode participar do processo de seleção de um Presidente temporário.


3.4  Processo de Desenvolvimento de Políticas

Qualquer pessoa pode enviar uma proposta. As propostas de política são enviadas para a lista de discussão Discussão sobre política de recursos (Este endereço de e-mail está protegido contra spambots. Você deve habilitar o JavaScript para visualizá-lo.) pelo autor. AFRINIC fornecerá suporte administrativo e auxiliará o (s) autor (es) em drafta proposta, se solicitado. A AFRINIC também fornecerá fatos e estatísticas relevantes, se solicitados durante a discussão.

3.4.1 Draft Proposta de política

Durante o desenvolvimento da política, draft versões do documento são disponibilizadas para revisão e comentários, publicando-as no site da AFRINIC e publicando-as no Este endereço de e-mail está protegido contra spambots. Você deve habilitar o JavaScript para visualizá-lo. lista de discussão. Cada draft A política recebe um identificador exclusivo da AFRINIC e o site da AFRINIC também deve conter o histórico da versão e o status de todas as propostas.

A draft a política deve estar disponível para revisão por pelo menos quatro semanas antes da próxima Reunião de Política Pública. O (s) autor (es) devem fazer as alterações necessárias no draft política de acordo com o feedback recebido. O (s) Presidente (s) do Grupo de Trabalho podem solicitar à AFRINIC que forneça uma análise (técnica, financeira, jurídica ou outra) do impacto do draft proposta de política.

A draft A política expira após um ano civil, a menos que seja aprovada pelo Conselho de Diretores da AFRINIC como uma política. O período de tempo limite é reiniciado quando o draft política é substituída por uma versão mais recente da proposta. UMA draft a política pode ser retirada pelo (s) autor (es) enviando uma notificação para a lista de discussão da Política de Recursos.

3.4.2 Reunião de Política Pública

A draft política é colocada na agenda de uma reunião de política pública aberta. A pauta da reunião será anunciada na lista de mala direta de Discussão da Política de Recursos pelo menos duas semanas antes da reunião. Nenhuma mudança pode ser feita em um draft política dentro de uma semana da reunião. Isso é para que uma versão estável do draft política pode ser considerada na reunião. O (s) Presidente (s) determinam se foi alcançado um consenso aproximado durante a Reunião de Políticas Públicas.

O (s) presidente (s) publicará a ata dos trabalhos da Reunião de Política Pública o mais tardar três semanas após a reunião.

3.4.3 Última Chamada

Uma revisão final do draft A política é iniciada pelo (s) Presidente (s) do Grupo de Trabalho enviando um anúncio para a lista de discussão de Política de Recursos. O período da Última Chamada será de pelo menos duas semanas. O (s) Presidente (s) do Grupo de Trabalho avaliarão o feedback recebido durante a Reunião de Políticas Públicas e durante este período e decidirão se o consenso foi alcançado.

3.4.4 Aprovação

O (s) Presidente (s) do Grupo de Trabalho deve recomendar o draft ao Conselho de Diretores da AFRINIC para aprovação se tiver o consenso do Grupo de Trabalho de Desenvolvimento de Políticas. A recomendação deve incluir um relatório das discussões do draft política e feedback da última chamada. o draft política será ratificada pelo Conselho de Administração da AFRINIC.

3.4.5 Implementação

A data de adoção e implementação da política é anunciada na lista de discussão Discussão sobre Políticas de Recursos. A data de implementação deve ser inferior a seis meses após o final da Última Chamada, a menos que uma renúncia seja solicitada.


3.5  Resolução de Conflitos

  1. Uma pessoa que não concordar com as ações tomadas pelo (s) presidente (s) deve discutir o assunto com o (s) presidente (s) do PDWG ou com o PDWG. Se o desacordo não puder ser resolvido dessa maneira, a pessoa poderá interpor um recurso junto a um Comitê de Apelação nomeado pelo Conselho de Administração da AFRINIC. Uma apelação só pode ser registrada se for apoiada por três (3) pessoas do Grupo de Trabalho que participaram das discussões.
  2. O apelo deve ser apresentado dentro de duas semanas após o conhecimento público da decisão. O Comitê de Apelação emitirá um relatório sobre sua análise da queixa ao Grupo de Trabalho. O Comitê de Apelação pode determinar que a decisão do Presidente seja anulada se o Processo de Desenvolvimento de Políticas não tiver sido seguido.
  3. Qualquer pessoa pode solicitar a revocação de um Presidente do Grupo de Trabalho a qualquer momento, mediante solicitação por escrito e com justificativa ao Conselho de Administração da AFRINIC. A solicitação deve ser apoiada por pelo menos cinco (5) outras pessoas do Grupo de Trabalho. O Conselho de Administração da AFRINIC nomeará um comitê de recall, excluindo as pessoas que solicitaram o recall e os presidentes dos grupos de trabalho. O comitê de recall deve investigar as circunstâncias da justificativa para o recall e determinar o resultado.

3.6  Variando o processo

O processo descrito neste documento pode variar em caso de emergência. A variação é para uso quando é necessária uma renúncia única de algumas disposições deste documento.

  1. A decisão de variar o processo é tomada por um presidente do grupo de trabalho.
  2. Deve haver uma explicação sobre por que a variação é necessária.
  3. O período de revisão, incluindo a Última Chamada, não deve ser inferior a quatro semanas.
  4. Se houver consenso, a política é aprovada e deve ser apresentada na próxima Reunião de Política Pública.

3.7  Draft Modelo de Política

A draft o texto da proposta de política deve ser apresentado no seguinte modelo:

Nome da proposta:

ID: (atribuído por AFRINIC)

Data Enviada:

Autor (es):

Versão:

Obsoletos:

Altera:

1. O problema abordado por esta proposta.

2. Como esta proposta aborda o problema.

3. Proposta

  • Use a subnumeração para facilitar a referência.
  • A proposta deve mostrar as seções exatas a serem modificadas e o conteúdo que deve ser adicionado ou removido do CPM.

4. Referências.

5. Histórico de revisões.

4.0 Hierarquia de distribuição de recursos numéricos

Os Recursos numéricos da Internet são distribuídos em uma estrutura hierárquica na qual a IANA (Autoridade de números atribuídos à Internet) aloca blocos de recursos numéricos para o AFRINIC, a serem redistribuídos em toda a região africana. A AFRINIC redistribui a seus membros e também delega a eles a autoridade para fazer atribuições e alocações aos clientes, quando apropriado e de acordo com as políticas e procedimentos descritos neste documento.

5.0 IPv4

Esta seção descreve as diretrizes para o gerenciamento responsável IPv4 espaço de endereço na região de serviço AFRINIC. As diretrizes são desenvolvidas por meio de um processo aberto e de baixo para cima de desenvolvimento de políticas do Grupo de Trabalho para Desenvolvimento de Políticas.


5.1  IPv4 Espaço de Endereço

Para os fins deste documento, IPv4 endereços são números binários de 32 bits (usados ​​como identificadores no IPv4 protocolo) e geralmente estão em três tipos:

5.1.1 Endereços IP públicos / globais que são atribuídos para serem globalmente únicos de acordo com os objetivos descritos na seção 5.2 deste documento.

5.1.2 Privado IPv4 espaço de endereçamento é reservado para uso em particular IPv4 redes. Qualquer pessoa pode usar esses endereços em suas redes privadas sem registro. Hosts com privado IPv4 os endereços não podem ser acessados ​​da Internet, a menos que sejam ativados por meio do NAT (Network Address Translation). Observe que alguns serviços da Internet podem não funcionar corretamente no NAT. Consulte o RFC 2993 para obter implicações técnicas / de engenharia do uso do NAT. O RFC1918 também descreve os blocos reservados para uso privado.

5.1.3 Intervalos de IP reservados para experimentos:

Estes são descritos na RFC3330 (https://www.ietf.org/rfc/rfc3330.txt).

Alguns intervalos também são reservados para multicast.


5.2  Objetivos do sistema de registro na Internet

5.2.1 Metas

É dever primordial de AFRINIC, como guardião de um recurso público, garantir que, para todos IPv4 alocações e atribuições, os seguintes objetivos são atingidos:

5.2.1.1 Singularidade - Para que cada host na Internet pública possa ser identificado exclusivamente, cada unicast público IPv4 O endereço deve ser globalmente exclusivo.

5.2.1.2 Registros - Cada atribuição e alocação de espaço de endereço público da Internet deve ser registrada no AFRINIC whois base de dados. Isso é necessário para garantir a exclusividade e fornecer informações para a solução de problemas da Internet em todos os níveis.

5.2.1.3 Agregação - Distribuindo Ipv4 endereços de uma maneira hierárquica permite a agregação de informações de roteamento. Isso ajuda a garantir a operação adequada do roteamento da Internet e a limitar a expansão das tabelas de roteamento da Internet (RFC2519).

5.2.1.4 Conservação - Para maximizar a vida útil do recurso público de espaço na Internet, os endereços devem ser distribuídos de acordo com a necessidade real e com base no uso imediato. Portanto, o armazenamento de espaço de endereço e a manutenção de reservas devem, em geral, ser evitados.

5.2.2 Conflito de metas

Os objetivos de conservação e agregação geralmente entram em conflito entre si. Algumas ou todas as metas podem ocasionalmente estar em conflito com os interesses de IRs individuais ou usuários finais. Portanto, os IRs que avaliam solicitações de alocações e atribuições devem analisar cuidadosamente todas as considerações relevantes e devem procurar equilibrar as necessidades do solicitante com as necessidades da comunidade da Internet como um todo. Essas políticas têm como objetivo ajudar os IRs a equilibrar essas necessidades de maneira justa. A documentação do processo de tomada de decisão para cada alocação ou atribuição ajuda a garantir que o processo permaneça transparente e honesto.

5.2.3 Documentação

Para avaliar adequadamente as solicitações, um RIR deve examinar cuidadosamente toda a documentação relevante relacionada às redes em questão. Essa documentação pode incluir planos de engenharia de rede, planos de sub-rede, descrições de topologia de rede e descrições de planos de roteamento de rede. Toda a documentação deve estar em conformidade com um padrão consistente e quaisquer estimativas e previsões documentadas devem ser realistas e justificáveis.

5.2.4 Justiça

Todas as políticas e práticas relacionadas ao uso do espaço de endereço público serão aplicadas de forma justa e equitativa a todos os membros existentes e potenciais da AFRINIC, independentemente de sua localização, nacionalidade, tamanho ou qualquer outro fator.


5.3  Requisitos de registro

5.3.1 Todas as comunicações com a AFRINIC serão em inglês.

5.3.2 Todas as alocações, atribuições de PI, atribuições de PA, sub-alocações e outros tipos de designações de recursos serão registradas no banco de dados do AFRINIC. Quaisquer recursos não registrados serão considerados inválidos. Os dados de registro (nome, bloco / intervalo de IP, contatos, status etc.) devem estar corretos o tempo todo. Isso é necessário para dar suporte às operações de rede.


5.4  Pouso suave

Esta seção descreve como o AFRINIC deve atribuir, alocar e gerenciar IPv4 recursos durante a "Fase de exaustão", que começa quando o AFRINIC primeiro precisa atribuir ou alocar endereços IP do bloco final / 8 de IPv4 espaço de endereço.

Para garantir uma transição suave para IPv6, O pool do AFRINIC deve ser gerenciado para fornecer aos membros espaço de endereço após o IPv4 a piscina está esgotada. Isso ajudará a manter IPv4 redes durante a implantação IPv6 redes - uma prática que caracteriza o período de transição. Esta seção propõe uma estratégia para alocação, cessão e manutenção de equipamentos da AFRINIC. IPv4 exaustão pós piscina. A aplicação da política de 'pouso suave' começa quando o AFRINIC começa a alocar espaço a partir da IANA final alocada / 8.

Este IPv4 A política de Soft Landing aplica-se ao gerenciamento do espaço de endereço que estará disponível para o AFRINIC após o atual IPv4 a piscina está esgotada. O objetivo deste documento é garantir que o espaço de endereçamento seja atribuído e / ou alocado de uma maneira aceitável para a comunidade AFRINIC, especialmente durante esse período de IPv4 exaustão.

5.4.1 Definições específicas para a seção de pouso suave:

  1. LIRs existentes - Um LIR existente é um LIR que atribui espaço de endereçamento a 'usuários finais' e já foi atribuído ou alocado IPv4 espaço de endereço do AFRINIC.
  2. Novo LIR - Um novo LIR, é um LIR que atribui espaço de endereço para 'usuários finais' e é um membro da AFRINIC, mas não foi atribuído ou alocado qualquer IPv4 espaço de endereçamento antes da fase de exaustão.
  3. Usuário final - Um usuário final é uma organização que recebe atribuições de endereços IP exclusivamente para uso em suas redes operacionais
  4. Final / 8 blocos de IPv4 espaço de endereço ou "Final / 8" - O bloco final / 8 de IPv4 espaço de endereço, ou "Final / 8", é o bloco / 8 IPv4 espaço de endereçamento atribuído pela IANA à AFRINIC nos termos da seção 2.2 C do Relatório Global Política de Alocação dos Restantes IPv4 Espaço de Endereço no momento da exaustão da piscina da IANA IPv4 espaço de endereço.

5.4.2 Fase atual.

A "Fase Atual" é o status quo no momento da adoção da política de aterrissagem suave. Durante esta fase, o AFRINIC continuará alocando ou atribuindo IPv4 endereços para LIRs e Usuários Finais usando diretrizes de diretiva de alocação e atribuição já em vigor.

A fase atual continuará até que uma solicitação válida para IPv4 o espaço de endereçamento de um LIR ou usuário final para o AFRINIC:

  1. Não pode ser cumprido com o IPv4 espaço de endereçamento disponível no pool AFRINIC (com exceção do Final / 8), ou
  2. Pode ser cumprido, mas deixaria o AFRINIC IPv4 pool de endereços vazio (com exceção do Final / 8).

A solicitação que resultar em uma das condições acima será cumprida será a última

IPv4 solicitação de espaço de endereço que o AFRINIC aceitará de qualquer LIR ou Usuário Final na Fase Atual. Se a solicitação puder ser processada nos termos das políticas da fase atual, será processada; caso contrário, será processado nos termos das políticas da fase de exaustão.

A AFRINIC anunciará publicamente que a Fase de Exaustão já começou neste momento. Para evitar dúvidas, todos os aplicativos que estão atualmente em processo neste momento serão avaliados de acordo com a nova política.

5.4.3 Fase de Exaustão

Durante a fase de exaustão, as seguintes diretrizes de alocação e atribuição serão usadas. Eles se aplicam a LIRs e Usuários Finais e a todos IPv4 endereço, espaço alocado, atribuído ou gerenciado pela AFRINIC durante a transição para e após o início da Fase de Esgotamento, independentemente de tal IPv4 O espaço de endereço faz parte do Final / 8. A fase de exaustão será dividida em duas partes:

5.4.3.1 Fase 1 de exaustão

Durante esta fase, a alocação / atribuição de espaço de endereço continuará como na fase atual (/ 24 para um EU e / 22 para um LIR), mas o máximo mudará de / 10 para / 13.

As alocações e atribuições serão feitas a partir da Final / 8 ou de qualquer outro IPv4 endereça o espaço disponível para o AFRINIC até que não haja mais que um / 11 de espaço não reservado no Final / 8. Nesse ponto, a Fase de exaustão 2 começará. Para evitar dúvidas, todos os aplicativos que estiverem em processo neste momento serão avaliados conforme a nova política.

5.4.3.2 Fase 2 de exaustão

Durante esta fase, um tamanho mínimo de alocação / atribuição será / 24 e o máximo será / 22 por alocação / atribuição.

5.4.4 Para qualquer solicitação de LIR ou Usuário Final IPv4 espaço de endereço durante o esgotamento: 

Não há limite explícito para o número de vezes que uma organização pode solicitar IPv4 espaço de endereço durante o período de exaustão.

5.4.5 O período atual de alocação e atribuição de 12 meses será alterado para 8 meses.

O atual período de alocação e atribuição de 12 meses será alterado para 8 meses. Isso ajudará a garantir que os LIRs solicitem apenas os recursos necessários a curto e médio prazo e promoverá a equidade na distribuição equitativa dos últimos IPv4 pool de endereços. Esse período de atribuição permanecerá o mesmo durante toda a vida útil desta Política.

5.4.6 Critérios de Alocação

5.4.6.1 Para receber IPv4 alocações ou atribuições durante a Fase de Exaustão, o LIR ou o Usuário Final deve ter usado pelo menos 90% de todas as alocações ou atribuições anteriores (incluindo aquelas feitas durante a Fase Atual e a Fase de Exaustão).

No caso de novos LIRs ou Usuários Finais sem alocações ou atribuições anteriores, esse requisito não se aplica à primeira solicitação de alocação ou atribuição.

5.4.6.2 Os recursos AFRINIC são para a região de serviço AFRINIC e qualquer uso fora da região deve ser apenas para apoiar a conectividade de volta à região AFRINIC.

5.4.7 IPv4 Reserva de Espaço de Endereço

5.4.7.1 A / 12 IPv4 O bloco de endereços estará na reserva fora do final / 8.

Este / 12 IPv4 O bloco de endereços deve ser preservado pela AFRINIC para alguns usos futuros, ainda não previstos. A Internet é inovadora e não podemos prever com certeza o que pode acontecer. Portanto, é prudente manter esse bloco em reserva, caso algum requisito futuro crie uma demanda por IPv4 Endereços.

5.4.7.2 Se o / 12 reservado permanecer sem uso até o momento em que o espaço disponível restante tenha sido alocado, o / 12 será devolvido ao pool AFRINIC para distribuição nas condições da fase 2 da política de pouso suave.

5.5 IPv4 Alocações LIR / ISP

5.5.1 Políticas e diretrizes de alocação

5.5.1.1 Introdução

5.5.1.1.1 AFRINIC aloca faixas de IPv4 endereços para Registros Locais da Internet (LIRs).

Os LIRs reatribuem ou subalocam esse espaço para seus clientes. Também é aconselhável que todo o espaço de endereçamento atribuído pelo LIR do AFRINIC adote um conjunto de políticas consistentes com as políticas descritas neste documento.

5.5.1.1.2 A determinação do tamanho da alocação do espaço de endereço IP é responsabilidade da equipe da AFRINIC.

Em um esforço para garantir que o CIDR (Roteamento entre domínios sem classe) seja implementado e utilizado da maneira mais eficiente possível, o AFRINIC emitirá blocos de IPv4 endereços nos limites de bits "suportados pelo CIDR" apropriados. (CIDR - "Roteamento entre domínios sem classe", é explicado na RFC1517-1959, https://www.ietf.org/standards/rfcs/).

5.5.1.1.3 Se um LIR planeja trocar ou transferir espaço de endereço, ele precisa entrar em contato com a AFRINIC para que as alterações sejam devidamente registradas.

O LIR permanece responsável por todas as alocações registradas no banco de dados do AFRINIC até que tenham sido transferidas para outro LIR ou devolvidas ao AFRINIC. Os LIRs devem garantir que todas as políticas sejam aplicadas.

5.5.1.2 Primeiro IPv4 Alocação

5.5.1.2.1 A alocação mínima do AFRINIC é / 22 ou 1024 IPv4 Endereços.

5.5.1.2.2 A organização deve ser um membro da AFRINIC em boa posição e;

5.5.1.2.3 Deve mostrar uma utilização eficiente existente dos endereços IP de seu provedor upstream.

A justificação pode basear-se em uma combinação de necessidade imediata e uso existente; nesse caso, as atribuições existentes devem ser renumeradas na nova alocação do LIR. A verificação da utilização eficiente anterior é baseada em atribuições (e subalocações) registradas nas bases de dados RIPE, ARIN, LACNIC e APNIC, e somente essas atribuições registradas serão consideradas válidas.

5.5.1.3 Mecanismo de início lento para primeiras alocações

O AFRINIC deve aplicar um mecanismo de partida lenta a todos os novos LIRs. Com relação às alocações feitas pela AFRINIC, a primeira alocação que um LIR recebe será do tamanho da alocação prática mínima, a menos que seja justificado de outra forma.

A política de início lento é usada por todos RIRpara impedir alocações de grandes blocos de espaço de endereço que podem permanecer substancialmente não atribuídos. O AFRINIC implementará o mecanismo de início lento de maneira consistente e justa para cada LIR e aplicará os mesmos princípios e padrões a todos os candidatos a espaço de endereçamento.

5.5.1.4 Alocação adicional

5.5.1.4.1 Um LIR pode receber uma alocação adicional quando cerca de 80% de todo o espaço de endereço atualmente alocado a ele tiver sido usado em atribuições válidas e / ou sub-alocações.

Uma nova alocação também pode ser feita se uma única atribuição ou subalocação exigir mais endereços do que aqueles atualmente mantidos pelo LIR.

5.5.1.4.2 As reservas não são consideradas como atribuições ou subalocações válidas.

Pode ser útil para a agregação interna manter alguns blocos de IP livres para crescimento futuro. No entanto, essas reservas internas não são consideradas como uso válido e devem ser atribuídas ou subalocadas antes de solicitar alocação adicional.

5.5.1.4.3 O AFRINIC sempre tentará alocar faixas de endereços contíguas, permitindo ao LIR minimizar o número de anúncios de rota que faz.

No entanto, nem sempre será possível alocar um intervalo de contíguos com a alocação anterior do LIR.

5.5.1.5 Subalocações

O tamanho mínimo de uma subalocação é / 24. Ele permite que um número razoável de pequenas atribuições seja feito por um ISP a jusante. Um LIR não pode subalocar IPv4 espaço acima de sua janela de subalocação (ver 5.5.1.13 para janelas de subalocação).

Os LIRs podem fazer sub-alocações para vários ISPs posteriores. (Os ISPs a jusante utilizam eficientemente uma subalocação qualificada para receber uma alocação / 22, caso desejem se tornar um LIR).

O LIR é responsável por garantir que o espaço de endereço alocado a ele e, posteriormente, o espaço de endereço alocado seja usado de acordo com as políticas e diretrizes da comunidade.

Os LIRs são aconselhados a usar o mecanismo de início lento ao fazer subalocações para ISPs a jusante. Aqui, o LIR garante que o espaço subalocado seja usado com eficiência e o LIR também pode monitorar e determinar a capacidade do ISP downstream de operar dentro das políticas definidas pela comunidade.

As subalocações fazem parte do espaço agregável de um LIR. Portanto, um LIR deve garantir que o espaço IP não seja retido pelo ISP downstream se o revendedor parar de obter conectividade da rede do LIR (as subalocações não são portáteis).

5.5.1.6 Políticas e diretrizes de atribuição de PA

Os LIRs devem solicitar a aprovação do AFRINIC para todas as subalocações acima de sua Janela de Subalocação.

As diretrizes a seguir têm como objetivo ajudar LIRs e usuários finais na busca de compromissos equitativos:

Documentação 5.5.1.7

As informações exigidas pelo AFRINIC para justificar os requisitos de endereço IP do usuário final incluem atender às necessidades, infraestrutura de rede e planos futuros. Essas informações são necessárias quando um LIR está solicitando espaço IP para seus usuários finais no momento do envio da solicitação. Para garantir que as subalocações anteriores não sejam duplicadas, o uso atual do espaço de endereço também é necessário. Essas informações são essenciais para fazer as aprovações de subalocação apropriadas e o nível de detalhe dependerá do tamanho da solicitação e da complexidade da rede. O LIR deve garantir que as informações necessárias sejam preenchidas antes de fazer uma solicitação de subalocação ao AFRINIC.

Ao fazer a subalocação a partir de sua SAW, os LIR também devem garantir que essas informações sejam fornecidas pelo usuário final.

5.5.1.8 Infraestrutura de rede (de LIR) vs redes de usuário final

Os endereços IP usados ​​exclusivamente para conectar um usuário final a um provedor de serviços (por exemplo, links ponto a ponto) são considerados parte da infraestrutura do provedor de serviços. Esses endereços devem ser registrados apenas como parte da infraestrutura do provedor de serviços. Quando um usuário final tem uma rede usando espaço de endereço público, esse espaço deve ser registrado com os contatos do usuário final. Se o usuário final for um indivíduo e não uma organização, o espaço pode ser registrado com as informações de contato do provedor de serviços, mas com o usuário final referenciado no AFRINIC whois objeto de banco de dados.

5.5.1.9 Utilização

A utilização imediata de atribuições deve ser de pelo menos 25% do espaço atribuído. Após um ano, a menos que circunstâncias especiais sejam definidas, deve ser de pelo menos 50%.

5.5.1.10 Reservas não suportadas

Os usuários finais não têm permissão para reservar espaço de endereço com base em planos de longo prazo. Isso viola o objetivo de conservação e fragmenta o espaço de endereço quando as previsões iniciais não são cumpridas. Se um LIR quiser atribuir espaço de endereçamento para clientes, ele deve fazer as atribuições a partir de qualquer espaço de endereçamento não alocado ou não atribuído que ele possui atualmente. Para fins de avaliação de solicitações de alocação, o espaço reservado por um LIR para outros clientes é considerado não utilizado.

5.5.1.11 Validade de uma tarefa

As atribuições permanecem válidas enquanto os critérios originais nos quais a atribuição foi baseada ainda estiverem em vigor e a atribuição for registrada no banco de dados AFRINIC. Portanto, uma atribuição é inválida se não estiver registrada no banco de dados e se a finalidade para a qual foi registrada tiver sido alterada ou não tiver mais validade.

5.5.1.12 Renumeração

Isso está substituindo os endereços IP individualmente. As atribuições válidas podem ser substituídas pelo mesmo número de endereços se os critérios de atribuição originais ainda forem atendidos. Os endereços a serem substituídos ainda devem estar em uso. Quando um pedido de renumeração excede a janela de subalocação do LIR, o pedido deve ser enviado ao AFRINIC para aprovação.

Um período de três meses é normalmente considerado suficiente para migrar uma rede para o novo espaço IP. Após a renumeração da rede, a equipe do AFRINIC removerá a antiga atribuição do banco de dados do AFRINIC. Caso o período de três meses não seja suficiente, o LIR deve informar o AFRINIC sobre o tempo adicional que pode levar para renumerar completamente.

5.5.1.13 Janela Subalocação (SAW)

5.5.1.13.1 Uma janela de subalocação (SAW) refere-se ao número máximo de IPv4 endereços que o LIR pode alocar para os usuários finais sem solicitar a aprovação do AFRINIC. O tamanho da SAW é expresso na notação CIDR.

5.5.1.13.2 O AFRINIC revisará a subalocação feita pelos LIRs usando sua SAW para garantir que as políticas sejam seguidas corretamente. Os LIR também devem garantir que a documentação para a subalocação feita usando a SAW seja semelhante à solicitada para solicitações maiores.

5.5.1.13.3 Abaixo estão algumas diretrizes para o SAW:

  1. Todos os novos LIRs têm uma SAW de zero. Todas as sub-alocações precisarão de aprovação prévia da AFRINIC.
  2. O LIR não pode fazer nenhuma subalocação para o usuário final acima de sua SAW em um período de 12 meses (1 ano). No final de um ano civil a partir da aprovação de uma SAW, a SAW é atualizada por mais um ano. Caso a SAW do LIR esteja esgotada para um usuário final específico, a AFRINIC deve obter a aprovação da AFRINIC para qualquer outra subalocação para o mesmo usuário final.
  3. Os LIRs são convidados a entrar em contato com o AFRINIC para uma revisão de suas VI. Eles também podem buscar uma segunda opinião da AFRINIC, mesmo para uma subalocação que poderia ser feita com a SAW, se assim o desejassem. Antes de uma SAW ser levantada, o seguinte será considerado:
    1. Toda a documentação necessária é normalmente apresentada.
    2. As atribuições de subalocação anteriores dessa subalocação são todas registradas corretamente no banco de dados.
    3. A SAW atual não foi usada / abusada.
  4. Os novos LIRs são aconselhados a treinar seus contatos para lidar com as atribuições de espaço de endereço de acordo com as políticas e procedimentos deste documento. Se, devido a contatos inexperientes no LIR, ocorrerem erros devido a um julgamento insuficiente, a SAW poderá ser reduzida ou removida para permitir que a equipe da AFRINIC ajude no treinamento da equipe da LIR nas políticas da comunidade da AFRINIC.

5.5.1.14 Manutenção de registros por LIRs

Os LIRs devem manter e manter registros de qualquer documentação referente a atribuições e sub-alocações a usuários finais. É necessário para referência futura ao avaliar solicitações da mesma organização e para quaisquer auditorias do AFRINIC. Esses documentos devem ser mantidos eletronicamente para facilitar o acesso. É recomendável que esses registros incluam, mas não se limitem a:

  1. A solicitação original.
  2. Documentação de suporte.
  3. Correspondência relacionada entre LIR e usuário final.
  4. A decisão da tarefa e as razões por trás de qualquer decisão incomum.
  5. Papel da pessoa que tomou a decisão.

5.6 IPv4 Atribuições de usuário final (PI)

AFRINIC atribui blocos de IPv4 endereços para usuários finais que solicitam espaço de endereço para uso interno na execução de suas próprias redes, mas não para subdelegação ou reatribuição desses endereços fora da organização. Os usuários finais devem atender a alguns requisitos para justificar a atribuição de um bloco de endereços.

5.6.1 Atribuição mínima

Em geral, o bloco mínimo de espaço de endereço IP atribuído pelo AFRINIC aos usuários finais é a / 24. Se forem necessárias atribuições menores que / 24, os usuários finais devem entrar em contato com o provedor upstream. Os prefixos atribuídos ao Usuário final serão de um bloco reservado para esse fim.

5.6.2 Critérios de atribuição do primeiro usuário final

Os usuários finais solicitantes devem:

  1. Seja um membro AFRINIC em boa posição
  2. Mostrar uma utilização eficiente existente de pelo menos / 25 do seu fornecedor upstream.
  3. Justifique uma necessidade imediata de pelo menos 50% do tamanho total solicitado, com base em sua infraestrutura de rede. Por exemplo, uma nova empresa.

5.6.3 Atribuição PI adicional

A taxa de utilização do espaço de endereço é um fator chave para justificar uma nova atribuição de espaço de endereço IP. Os solicitantes devem mostrar exatamente como as atribuições de endereços anteriores foram utilizadas e devem fornecer detalhes apropriados para verificar sua projeção de crescimento em um ano. Os critérios básicos que devem ser atendidos são:

  1. Uma taxa de utilização imediata de 25% e 
  2. Uma taxa de utilização de 50% em um ano. 

Uma taxa de utilização maior pode ser necessária com base nos requisitos de rede individuais. Endereço IP privado: Os usuários finais que não estão conectados no momento a um provedor de serviços de Internet e / ou planejam não estar conectados à Internet são incentivados a usar números IP privados reservados para redes não conectadas (consulte a RFC 1918).

5.6.4 Atribuições de PI para infraestrutura crítica

5.6.4.1 A AFRINIC fará a atribuição do usuário final a provedores de infra-estrutura crítica da Internet, como pontos de troca de Internet públicos e provedores de serviços DNS básicos.

Essas alocações não terão mais que um / 24 usando IPv4. Alocações múltiplas podem ser concedidas em determinadas situações. As atribuições de pontos de troca DEVEM ser emitidas a partir de blocos específicos reservados apenas para esse fim.

5.6.4.2 O AFRINIC disponibilizará publicamente uma lista desses blocos.

5.6.4.3 Operadores de ponto de troca devem fornecer justificativa para a alocação, incluindo política de conexão, localização, outros participantes (mínimo de três no total), ASNe informações de contato.

Esta política não impede os operadores de ponto de câmbio de solicitar espaço de endereço sob outras políticas, como tornar-se LIR.

5.6.4.4 Definições:

5.6.4.4.1 Ponto de Troca:

Um ponto de intercâmbio na Internet é definido como uma infraestrutura de rede física (camada 2) operada por uma única entidade cujo objetivo é facilitar a troca de tráfego da Internet entre os ISPs. Deve haver no mínimo três ISPs conectados e deve haver uma política clara e aberta para que outras pessoas participem. Os endereços necessários para outros fins (por exemplo, serviços adicionais fornecidos aos membros) devem ser adquiridos pelos meios apropriados (por exemplo, um ISP upstream).

5.6.4.4.2 Fornecedor de serviços DNS principal:

Um provedor de serviços DNS principal é uma empresa que fornece serviço DNS para o nível raiz da árvore DNS (operadores raiz sancionados pela ICANN).


5.7 IPv4 Transferência de recursos na região de AFRINIC

Como os outros Registros Regionais da Internet, o AFRINIC esgotará em breve IPv4 piscina. Para atender às necessidades dos solicitantes de recursos atrasados, uma política de transferência para IPv4 recursos na região são necessários. O objetivo desta política é definir condições sob as quais as transferências devem ocorrer. A política resolve o problema de uma organização africana que precisa IPv4 número de recursos após o esgotamento do AFRINIC IPv4 ou quando o AFRINIC não puder mais atender às necessidades de tal organização.

5.7.1 Resumo da política

Esta política se aplica a uma organização com uma necessidade justificada de IPv4 recursos que não podem ser satisfeitos pelo AFRINIC.

5.7.2 IPv4 recursos a serem transferidos - deve ser de uma conta de membro existente do AFRINIC ou de um detentor de recursos herdados na região de serviço do AFRINIC.

5.7.3 Condições sobre a fonte da transferência

5.7.3.1 A fonte deve ser o atual detentor dos direitos do IPv4 abordar os recursos reconhecidos pela AFRINIC e não participar de nenhuma disputa quanto ao status desses recursos.

5.7.3.2 As entidades de origem não serão elegíveis para receber mais IPv4 alocações ou atribuições de endereços da AFRINIC por um período de 12 meses após a aprovação da transferência.

5.7.3.3 As entidades de origem não devem ter recebido transferência, alocação ou atribuição de IPv4 número de recursos da AFRINIC nos 12 meses anteriores à aprovação da solicitação de transferência. Esta restrição exclui transferências de fusões e aquisições.

5.7.4 Condições sobre o destinatário da transferência

5.7.4.1 AFRINIC deve aprovar a necessidade do destinatário da IPv4 recursos numéricos. Para que uma organização se qualifique para receber uma transferência, ela deve primeiro passar pelo processo de justificar sua IPv4 necessidades de recursos antes do AFRINIC. Ou seja, a organização deve justificar e demonstrar perante o AFRINIC seu uso inicial / adicional de alocação / atribuição, conforme aplicável, de acordo com as políticas em vigor.

5.7.4.2 O destinatário deve ser um membro da AFRINIC, sujeito às políticas atuais da AFRINIC e deve assinar o Contrato de Serviços de Registro para obter os recursos recebidos.

5.7.4.3 Transferido IPv4 recursos herdados não serão mais considerados recursos herdados. 

6.0 IPv6

Esta seção define políticas de registro para a atribuição e alocação de recursos exclusivos globalmente. IPv6 endereços para Internet Service Providers (LIRs) e outras organizações na região de AFRINIC.

Em particular, recomenda a atribuição de / 48 no caso geral e / 64 quando se sabe que uma e apenas uma sub-rede é necessária (ou seja, links ponto a ponto ou um contexto PDP celular). Para mais detalhes, leia RFC6177 - https://tools.ietf.org/html/rfc6177 .



6.1 Usar

Ao contrário IPv4, IPv6 geralmente é atribuído aos sites finais em valores fixos. O uso real de endereços em cada atribuição será baixo quando comparado com IPv4 atribuições. Dentro IPv6, "utilização" é medida apenas em termos do número de prefixos atribuídos aos Sites finais, não do tamanho ou do número de endereços realmente usados ​​nesses prefixos.

6.2 Proporção HD

O HD-Ratio é uma maneira de medir a eficiência da atribuição de endereços [RFC 3194]. É uma adaptação da H-Ratio originalmente definida em [RFC1715] e é expressa da seguinte forma:

                 Log (número de objetos alocados)

HD = ------------------------------------------------ ----------

                   Log (número máximo de objetos alocáveis)

onde (no caso deste documento) os objetos são IPv6 endereços de site (/ 48s) atribuídos a partir de um IPv6 prefixo de um determinado tamanho.


6.3 Objetivos de IPv6 gerenciamento de espaço de endereço

IPv6 O espaço de endereço é um recurso público que deve ser gerenciado de maneira prudente em relação aos interesses de longo prazo da Internet. O gerenciamento responsável do espaço de endereçamento envolve equilibrar um conjunto de objetivos que às vezes competem. A seguir, são apresentados os objetivos relevantes para IPv6 política de endereço.

6.3.1 Unicidade:

Toda atribuição e / ou alocação de espaço de endereço deve garantir exclusividade em todo o mundo. Este é um requisito absoluto para garantir que todos os hosts públicos na Internet possam ser identificados de maneira exclusiva.

6.3.2 Registro

O espaço de endereço da Internet deve ser registrado em um banco de dados do registro acessível aos membros apropriados da comunidade da Internet. Isso é necessário para garantir a exclusividade de cada endereço da Internet e fornecer informações de referência para solução de problemas da Internet em todos os níveis, desde todos RIRse IRs para Usuários Finais.

O objetivo do registro deve ser aplicado dentro do contexto de considerações razoáveis ​​sobre privacidade e leis aplicáveis.

6.3.3 Agregação

Sempre que possível, o espaço de endereço deve ser distribuído de maneira hierárquica, de acordo com a topologia da infraestrutura de rede. Isso é necessário para permitir a agregação de informações de roteamento pelos ISPs e limitar a expansão das tabelas de roteamento da Internet.

Esse objetivo é particularmente importante em IPv6 endereçamento, em que o tamanho do pool total de endereços cria implicações significativas para o roteamento interno e externo.

IPv6 as políticas de endereço devem procurar evitar a fragmentação dos intervalos de endereços.

Além disso, RIRs devem aplicar práticas que maximizem o potencial de alocações subsequentes serem contíguas às alocações passadas atualmente mantidas. No entanto, não há garantia de alocação contígua.

6.3.4 Conservação

Apesar IPv6 fornece um pool de espaço de endereço extremamente grande; as políticas de endereço devem evitar práticas desnecessariamente desnecessárias. As solicitações de espaço de endereço devem ser suportadas por documentação apropriada e o armazenamento de endereços não utilizados deve ser evitado.

6.3.5 Justiça

Todas as políticas e práticas relacionadas ao uso do espaço de endereço público devem ser aplicadas de forma justa e equitativa a todos os membros existentes e potenciais da comunidade da Internet, independentemente de sua localização, nacionalidade, tamanho ou qualquer outro fator.

6.3.6 sobrecarga minimizada

É desejável minimizar a sobrecarga associada à obtenção do espaço de endereço. A sobrecarga inclui a necessidade de voltar ao RIRs para espaço adicional com muita freqüência, a sobrecarga associada ao gerenciamento do espaço de endereço que cresce por meio de várias expansões incrementais sucessivas pequenas, em vez de por expansões menores, mas maiores.

6.3.7 Conflito de metas

Os objetivos descritos acima frequentemente conflitam entre si ou com as necessidades de IRs ou usuários finais individuais. Todos os IRs que avaliam solicitações de alocações e atribuições devem fazer julgamentos, buscando equilibrar as necessidades do solicitante com as da comunidade da Internet como um todo.

In IPv6 política de endereço, o objetivo da agregação é considerado o mais importante.


6.4  IPv6 Princípios de política

Para abordar os objetivos descritos na seção anterior, as políticas neste documento discutem e seguem os princípios básicos descritos abaixo.

6.4.1 O espaço de endereçamento não deve ser considerado propriedade.

É contrário aos objetivos deste documento e não é do interesse da comunidade da Internet como um todo que o espaço de endereço seja considerado propriedade livre.

As políticas neste documento baseiam-se no entendimento de que globalmente único IPv6 O espaço de endereço unicast é licenciado para uso, e não de propriedade.

6.4.2 Roteabilidade não garantida

Não há garantia de que qualquer alocação ou atribuição de endereço seja globalmente roteável. Contudo, RIRs deve aplicar procedimentos que reduzam a possibilidade de espaço de endereço fragmentado, o que pode levar a uma perda de roteabilidade.

6.4.3 Alocação mínima

RIRs aplicará um tamanho mínimo para IPv6 alocações para facilitar a filtragem baseada em prefixos. O tamanho mínimo de alocação para IPv6 o espaço de endereço é / 32.

6.4.4 Consideração de IPv4 infra-estrutura

Onde um IPv4 solicitações do provedor de serviços IPv6 espaço para a eventual transição dos serviços existentes para IPv6, o número de presentes IPv4 os clientes podem ser usados ​​para justificar uma solicitação maior do que seria justificada se baseada apenas no IPv6 a infraestrutura.


6.5  Políticas para alocações e atribuições

6.5.1 Alocação inicial

6.5.1.1 Critérios de alocação inicial

Para se qualificar para uma alocação inicial de IPv6 espaço de endereçamento, uma organização deve:

  1. Seja um LIR;
  2. Mostre um plano detalhado para fornecer IPv6 conectividade / serviços a outras organizações / usuários finais ou departamentos / entidades / sites próprios / relacionados / relacionados na região de AFRINIC.
  3.  Mostre um plano razoável para fazer / 48 IPv6 atribuições a locais finais na região de AFRINIC dentro de doze meses.

 6.5.1.2 Tamanho da alocação inicial

  1. As organizações que atendem aos critérios de alocação inicial são elegíveis para receber uma alocação mínima de / 32.
  2. As organizações podem se qualificar para uma alocação inicial maior que / 32 enviando documentação que justifique a solicitação.
  3. Nesse caso, a alocação inicial deve basear-se no espaço necessário para atender os clientes da organização, número de usuários, extensão de sua infraestrutura, estrutura hierárquica e / ou geográfica, segmentação de infraestrutura por segurança ou outros motivos e longevidade prevista para a alocação inicial.

6.5.1.3 Retificando o tamanho das alocações iniciais

Durante IPv6 implantação, se uma organização considerar que o tamanho da alocação inicial solicitada não satisfaz mais suas necessidades, a organização pode enviar um novo plano de endereçamento para a AFRINIC, sem ter que esperar até que possa cumprir os requisitos para uma alocação subsequente e, portanto, o a organização não precisará provar os limites de utilização, mas, em vez disso, o desejo de aplicar um plano de endereçamento diferente que seja mais adequado à realidade da implantação.

O novo tamanho será ajustado de acordo com o novo plano de endereçamento, conforme especificado na seção 6.5.1.2., E assim se qualificará para estender o prefixo atual ao número necessário de bits.

Caso não seja possível fornecer esse tamanho de prefixo porque o espaço adjacente já está sendo usado por outra organização ou se a alocação não deixar espaço suficiente para alocações subsequentes, o AFRINIC informará o solicitante, que poderá optar por:

  1. Receba um novo prefixo com o novo tamanho solicitado, renumere sua rede e retorne a alocação inicial "original" dentro de 6 meses, ou
  2. Receba um prefixo complementar para concluir o plano de endereçamento e anuncie o prefixo inicial "original" e o novo prefixo resultante da nova alocação. Para todos os efeitos, no caso de alocações subsequentes, ambas as alocações serão consideradas como se fossem uma alocação única.

Cada organização pode usar esse procedimento apenas uma vez; portanto, para essa "segunda oportunidade", eles devem estudar cuidadosamente os planos finais de endereçamento de rede a médio e longo prazo.

6.5.2 Alocação subsequente

Organizações que possuem um IPv6 alocação pode receber uma alocação subsequente de acordo com as políticas a seguir.

6.5.2.1 Critérios de alocação subsequentes

A alocação subsequente será fornecida quando uma organização (LIR) atender ao limite de avaliação da utilização de endereços anteriores em termos do número de sites em unidades de / 48 atribuições. A relação HD [RFC 3194] é usada para determinar os limites de utilização que justificam a alocação de endereço adicional, conforme descrito abaixo.

6.5.2.2 Taxa de HD aplicada

O valor da relação HD de 0.94 é adotado como indicando uma utilização aceitável de endereço para justificar a alocação de espaço de endereço adicional. A Seção 6.7 fornece uma tabela mostrando o número de atribuições necessárias para atingir um valor de utilização aceitável para um determinado tamanho de bloco de endereço.

6.5.2.3 Tamanho de Alocação Subseqüente

  1. Quando uma organização alcança uma utilização aceitável do seu espaço de endereço alocado, é imediatamente elegível para obter uma alocação adicional que resulta na duplicação do espaço de endereço que foi alocado anteriormente. Onde possível, a alocação será feita a partir de um bloco de endereços adjacente, o que significa que sua alocação existente será estendida um bit para a esquerda.
  2. Se uma organização precisar de mais espaço de endereçamento, ela deverá fornecer documentação justificando o espaço necessário para atender seus clientes, número de usuários, extensão de sua infraestrutura, estrutura hierárquica e / ou geográfica, segmentação de infraestrutura por segurança ou outros motivos, e o longevidade prevista para a alocação inicial.

6.5.3 Alocação de LIR para ISP

Não existe uma política específica para uma organização (LIR) alocar espaço de endereço para ISPs subordinados. Cada organização LIR pode desenvolver sua própria política para ISPs subordinados, a fim de incentivar a utilização ideal do bloco de endereços total alocado ao LIR. No entanto, todas as / 48 atribuições aos sites finais precisam ser registradas pelo LIR ou por seus ISPs subordinados de forma que o RIR pode avaliar adequadamente o HD-Ratio quando uma alocação subsequente se tornar necessária.

6.5.4 Atribuições

LIRs devem fazer IPv6 atribuições de acordo com as seguintes disposições.

6.5.4.1 Atribuição de tamanho do espaço de endereço

As atribuições devem ser feitas de acordo com a necessidade especificada pelos usuários dos LIRs, bem como com outras recomendações existentes, como [RIPE-690 - https://www.ripe.net/publications/docs/ripe-690], cujos destaques estão resumidos abaixo:

  1. Aos sites ou usuários finais deve ser atribuído um prefixo que seja múltiplo de "n" / 64, suficiente para atender às necessidades atuais e planejadas, considerando protocolos existentes e possibilidades futuras, evitando possíveis cenários de renumeração.
  2. O tamanho do prefixo a ser atribuído é uma decisão operacional do LIR, embora a seleção de / 48s seja recomendada para uma infraestrutura mais simples e funcional para todos os pontos de extremidade da rede.
  3. Recomendações de prefixo persistentes são recomendadas para evitar falhas indesejadas.
  4. É recomendado o uso de um prefixo / 64 para links ponto a ponto com GUAs (Endereços Unicast Globais).

O AFRINIC não está preocupado com o tamanho do prefixo que um LIR atribui. Consequentemente, o AFRINIC não solicitará informações detalhadas sobre IPv6 redes de usuários (como em IPv4), exceto nos casos descritos na seção 6.5.2 e com a finalidade de medir a utilização.

6.5.4.2 Atribuição à infraestrutura do operador

Uma organização (LIR) pode atribuir um / 48 por PoP como a infraestrutura de serviço de um IPv6 operador de serviço. Cada atribuição a um PoP é considerada como uma atribuição, independentemente do número de usuários que usam o PoP. Uma atribuição separada pode ser obtida para as operações internas do operador.

6.5.5 Registro

Quando uma organização (LIR) detentora de uma IPv6 alocação de endereços faz IPv6 atribuições de endereço, ele deve registrar as informações de atribuição no banco de dados do AFRINIC. As informações são registradas em unidades de / 48 redes atribuídas. Quando mais de / 48 é atribuído a uma organização, a organização responsável é responsável por garantir que o espaço de endereço seja registrado no banco de dados AFRINIC.

O AFRINIC usará os dados registrados para calcular a taxa de HD no momento do pedido para alocação subsequente e verificar alterações nas atribuições ao longo do tempo.

O AFRINIC deve manter sistemas e práticas que protegem a segurança das informações pessoais e comerciais usadas na avaliação de solicitações, mas que não são necessárias para o registro público.

6.5.6 Pesquisa reversa

Quando um AFRINIC delega IPv6 espaço de endereçamento para uma organização, ele também delega a responsabilidade de gerenciar a zona de pesquisa inversa que corresponde ao alocado IPv6 espaço de endereço. Cada organização deve gerenciar adequadamente sua zona de pesquisa inversa. Ao fazer uma atribuição de endereço, a organização deve delegar a uma organização designada, mediante solicitação, a responsabilidade de gerenciar a zona de pesquisa inversa que corresponde ao endereço atribuído.

6.5.7 Existente IPv6 titulares de espaço de endereço 

Organizações que receberam / 35 IPv6 atribuições ao abrigo do anterior IPv6 política de endereço [RIRv6-Policies] têm o direito imediato de expandir sua alocação para um bloco de endereços / 32, sem fornecer justificativa, desde que atendam aos critérios acima. O bloco de endereços / 32 conterá o bloco de endereços menor já alocado (um ou vários / 35 blocos de endereço em muitos casos) que já foi reservado pelo RIR para uma alocação subsequente à organização. Solicitações de espaço adicional além do tamanho mínimo / 32 serão avaliadas conforme discutido em outras partes do documento.


6.6  Tarefas para experiências na Internet

As organizações geralmente exigem testes de implantação para novos serviços e tecnologias da Internet. Isso requer recursos de numeração para a duração do teste.

O objetivo da política de conservação de recursos é de importância reduzida quando os recursos são emitidos temporariamente.

6.6.1 Definindo o experimento

Uma organização que recebe recursos de numeração deve documentar o experimento. Isso pode estar na forma de uma RFC experimental da IETF atual. RFC2026, ou uma "proposta de experimento" detalhando os recursos necessários e as atividades a serem realizadas.

O tamanho da atribuição será igual ao tamanho mínimo de alocação existente na data em que a solicitação for recebida. Nos casos em que o experimento requer uma variação dessa regra, isso deve ser observado na solicitação de recurso.

6.6.2 Publicação

A proposta do experimento deve ser tornada pública (por exemplo, publicada no site), mediante o registro dos recursos pela AFRINIC. Após a conclusão do experimento, os resultados devem ser publicados gratuitamente e sem restrições de divulgação.

6.6.3 Base não comercial

Os recursos emitidos para um experimento não devem ser usados ​​para fins comerciais.

6.6.4 Período de Registro de Recurso Temporário.

Os recursos serão emitidos temporariamente por um período de um ano. A renovação do registro do recurso é possível após o recebimento de uma nova solicitação que detalha qualquer continuação do experimento durante o período prolongado.

Os recursos emitidos não podem ser utilizados para um serviço comercial após a conclusão do experimento.

6.6.5 Registro

AFRINIC irá registrar os recursos emitidos no AFRINIC whois base de dados.


6.7  Proporção HD (HD) e limiar de utilização (T)

O HD-Ratio não se destina a substituir a medição tradicional de utilização que os ISPs realizam IPv4 hoje. De fato, o HD-Ratio ainda exige contar o número de objetos atribuídos. O valor principal da relação HD é sua utilidade na determinação de valores-limite de utilização de destino razoáveis ​​para um espaço de endereço de um determinado tamanho. Este documento usa o HD-Ratio para determinar os limites nos quais uma determinada alocação alcançou um nível aceitável de utilização e a atribuição de espaço de endereço adicional se justifica.

O limite de utilização T, expresso como um número de prefixos individuais / 48 a serem alocados IPv6 prefixo P, pode ser calculado como:

T = 2 ((48-P) * HD)

Assim, o limite de utilização para uma organização que solicita alocação subsequente de IPv6 O bloco de endereços é especificado como uma função do tamanho do prefixo e da proporção HD de destino. Essa utilização refere-se à alocação de / 48s aos Sites Finais, e não à utilização desses / 48s nesses Sites Finais. É uma taxa de utilização de alocação de endereço e não uma taxa de utilização de atribuição de endereço.

De acordo com as recomendações da [RFC 3194], este documento adota um HD-Ratio de 0.94 como o limite de utilização para IPv6 alocações de espaço de endereço.

A tabela a seguir fornece valores absolutos equivalentes e percentuais de utilização de endereços para IPv6 prefixos, correspondentes a um HD-Ratio de 0.94.

P

48-P

Total / 48s

Limite

Util%

48

0

1

1

100.0%

47

1

2

2

95.93%

46

2

4

4

92.02%

45

3

8

7

88.27%

44

4

16

14

84.67%

43

5

32

26

81.23%

42

6

64

50

77.92%

41

7

128

96

74.74%

40

8

256

184

71.70%

39

9

512

352

68.78%

38

10

1024

676

65.98%

37

11

2048

1296

63.29%

36

12

4096

2487

60.71%

35

13

8192

4771

58.24%

34

14

16384

9153

55.86%

33

15

32768

17560

53.59%

32

16

65536

33689

51.41%

31

17

131072

64634

49.31%

30

18

262144

124002

47.30%

29

19

524288

237901

45.38%

28

20

1048576

456419

43.53%

27

21

2097152

875653

41.75%

26

22

4194304

1679965

40.05%

25

23

8388608

3223061

38.42%

24

24

16777216

6183533

36.86%

23

25

33554432

11863283

35.36%

22

26

67108864

22760044

33.92%

21

27

134217728

43665787

32.53%

20

28

268435456

83774045

31.21%

19

29

536870912

160722871

29.94%

18

30

1073741824

308351367

28.72%

17

31

2147483648

591580804

27.55%

16

32

4294967296

1134964479

26.43%

15

33

8589934592

2177461403

25.35%

14

34

17179869184

4177521189

24.32%

13

35

34359738368

8014692369

23.33%

12

36

68719476736

15376413635

22.38%

11

37

137438953472

29500083768

21.46%

10

38

274877906944

56596743751

20.59%

9

39

549755813888

108582451102

19.75%

8

40

1099511627776

208318498661

18.95%

7

41

2199023255552

399664922315

18.17%

6

42

4398046511104

766768439460

17.43%

5

43

8796093022208

1471066903609

16.72%

4

44

17592186044416

2822283395519

16.04%


6.8  Atribuições PI

Esta política visa fornecer IPv6 endereçar espaço para sites finais.

6.8.1 Introdução

Esta política permite que 'sites finais' sejam atribuídos IPv6 endereços independentes de provedor (PI). 'Sites finais' incluem Usuários finais e provedores críticos de infraestrutura, como operadores de servidores raiz de DPNs e pontos públicos de troca de Internet (IXP).

6.8.2 Critérios de Atribuição

  1. Destino da atribuição - sites finais que fornecem serviços públicos de Internet para a rede de uma única organização administrativa, independentemente do tamanho.
  2. Critérios de atribuição:
    Eu. O site final não deve ser um LIR
    ii. O site final deve se tornar um Membro do usuário final do AFRINIC e pagar a taxa normal do AFRINIC pela sua categoria de associação
    iii. O site final deve justificar a necessidade de IPv6 Espaço de endereço PI.
    iv. O site final deve mostrar um plano para usar o IPv6 espaço de endereço independente do provedor dentro de doze (12) meses. Após esse período, se não for anunciado, o designado IPv6 O espaço de endereço PI deve ser recuperado e devolvido ao pool gratuito pelo AFRINIC.
    v. IPv6 O espaço de endereço independente do provedor a ser anunciado pelo site final não deve ser desagregado.

6.8.3 Espaço de endereço independente do provedor (PI):

  1. A atribuição independente de provedor (PI) deve ser feita a partir de um bloco específico.
  2. O tamanho da atribuição independente do provedor inicial para um site final deve ser um / 48, ou um prefixo mais curto se o site final puder justificá-lo.
  3. As tarefas subsequentes devem ser documentadas e justificadas. Onde possível, essas atribuições serão feitas a partir de um bloco de endereços contíguo (ou seja, estendendo os bits "n" de atribuição existentes para a esquerda).

6.8.4 Retificando o tamanho de uma atribuição inicial

  1. Um site final pode enviar um novo plano de endereçamento para a AFRINIC se o plano inicialmente enviado para justificar a atribuição inicial não atender mais às suas necessidades atuais.
  2. A nova atribuição será consistente com o novo plano e obedecerá com 6.8.2 e 6.8.3.
  3. Se possível, o mesmo bloco de endereço será "atualizado" para o novo tamanho de prefixo necessário. No entanto, se os prefixos adjacentes já estiverem sendo usados ​​por outras organizações ou se essa tarefa não deixar espaço suficiente para tarefas subsequentes, o AFRINIC informará a organização solicitante, que terá as seguintes opções:
    Eu. Receba um novo bloco com o novo tamanho de prefixo solicitado, com o compromisso de renumerar sua rede e retornar o bloco original dentro de um período de 6 meses;
    ii. Receba um novo bloco que, juntamente com o bloco que já foi atribuído, cubra a nova necessidade justificada e mantenha os dois blocos.
    Este procedimento pode ser usado apenas uma vez por cada site final.

6.8.5 “Sub-atribuições” não permitidas.

É permitido usar os endereços atribuídos para:

  1. a rede do responsável pela atribuição
  2. dispositivos de terceiros que operam nessa infraestrutura
  3. interconexões 

Será considerada uma sub-atribuição e, consequentemente, não é permitido usar os endereços atribuídos para fornecer serviços aos clientes (como um ISP), data center ou casos semelhantes.

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  Objetivo

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 ao mesmo tempo que 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

Os seguintes termos e definições são usados ​​neste documento.

  1. Sistema Autônomo (AS) - Um Sistema Autônomo (AS) é um grupo conectado de um ou mais prefixos IP executados por uma ou mais operadoras de rede sob uma única política de roteamento claramente definida.
  2. Número do sistema autônomo (ASN)
    • Um número de sistema autônomo (ASN) é um número inteiro único associado a um AS. o ASN é usado como um identificador para permitir que o AS troque informações de roteamento dinâmico com outros sistemas autônomos.
    • Protocolos de roteamento externo (como o Border Gateway Protocol (BGP) descrito na RFC 1771) são usados ​​com ASNs para trocar informações entre redes. Um AS normalmente usa algum protocolo de gateway interno para trocar informações de roteamento em suas redes internas.
    • Em 1 2011 janeiro, RIRs deixou de fazer qualquer distinção entre números de AS de apenas 2 bytes e números de AS de 4 bytes e operar alocações de números de AS a partir de um pool de alocação de números de AS de 4 bytes não diferenciado. De acordo com RFC6793 - https://tools.ietf.org/html/rfc6793, o conjunto de 4 bytes de ASNs é 0-4294967295.
  3. Rede Multi-homed - Um AS multihomed é aquele que está conectado a mais de um outro AS. Um AS também se qualifica como multihomed se estiver conectado a um Internet Exchange Point público.
  4. Política de roteamento - A política de roteamento de um AS é uma descrição de como os prefixos de rede são trocados entre esse AS e outros sistemas autônomos.
  5. objeto aut-num - Um objeto aut-num é um objeto no whois banco de dados usado para registrar ASN detalhes da atribuição.

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 cumprir os 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.5  Considerações sobre propriedade e roteamento

7.5.1 Propriedade

A comunidade da Internet considera ASNs como um recurso público que só deve ser distribuído de acordo com a necessidade demonstrada. Nem a atribuição nem o registro conferem a propriedade dos recursos. Organizações que usam ASNs são considerados "custodiantes" em vez de "proprietários" do recurso e não têm o direito de vender ou transferir esse recurso para outras partes.

7.5.2 Considerações de roteamento

Gerenciamento responsável de ASNs é necessário para ajudar a limitar a expansão das tabelas de roteamento global. A agregação de prefixos de endereços IP contíguos em sistemas autônomos únicos ajuda a minimizar o número de rotas anunciadas para a Internet global.


7.6  Procedimentos de Cessão

O AFRINIC atribui Números AS para Sistemas Autônomos localizados na região de serviço do AFRINIC e aceita solicitações de LIRs, não membros da LIR e não membros que cumpram os requisitos de elegibilidade na Seção 7.4 deste documento.

A AFRINIC pode solicitar essas informações que podem ajudar a entender a política de roteamento planejada e decidir se um Número AS é realmente necessário.

7.6.1 Usando ASNs para rede LIRs

Atribuições a ISPs que usarão o ASN em sua própria rede estão sujeitos aos seguintes termos:

  1. O ISP solicitante é responsável por manter o registro descrito na Seção 7.7.
  2. O ISP solicitante tem o direito de continuar usando o ASN, mesmo que eles alterem colegas de rede ou provedores de serviços.

Os LIRs com AFRINIC não receberão nenhuma taxa anual de manutenção por ASNs.

7.6.2 Fornecendo ASNs para não-LIRs

As atribuições a quaisquer outras organizações que não sejam LIRs estão sujeitas aos seguintes termos:

  1. A empresa que realmente usará o ASN deve atender aos critérios acima.
  2. A empresa solicitante é responsável por manter o registro descrito abaixo.
  3. Será cobrada uma taxa de registro única por cada ASN conforme descrito na Tabela de Taxas do AFRINIC. A cada três anos a partir de então, o AFRINIC faturará à organização uma taxa de manutenção anual, pagável na data de aniversário da tarefa original.

7.7  Requisitos de registro

Todos ASNs atribuídos devem ser registrados publicamente no AFRINIC whois base de dados. AFRINIC criará o objeto 'aut-num' no banco de dados.

Todos os atributos do objeto 'aut-num' devem ser devidamente registrados de acordo com o AFRINIC whois documentação do banco de dados.

7.7.1 Registrando pessoas de contato

As pessoas de contato administrativas e técnicas devem ser registradas para cada ASN atribuído. O contato administrativo registrado ('admin-c') é a pessoa responsável pela ASN e geralmente deve ser alguém fisicamente localizado no local do AS.

O contato técnico ('tech-c') não precisa estar fisicamente localizado no local do AS, mas deve ser uma pessoa responsável pela operação diária desse AS.

7.7.2 Política de roteamento de registro

A AFRINIC recomenda que a política de roteamento do AS seja registrada em whois Banco de dados de cada ASN atribuído.

7.7.3 Atualizando detalhes de registro

LIR é responsável por ASNs devem atualizar o objeto 'aut-num' no AFRINIC whois banco de dados se alguma das informações de registro mudar.


7.8  Retornando sem uso ASNs

Se um ASN não está sendo usado pela organização que o recebeu originalmente, ele deve ser devolvido. O AFRINIC o devolverá ao pool público do AS Numbers para reatribuição a outro sistema autônomo na região do AFRINIC.


7.9  Variado

AFRINIC pode publicar outras diretrizes relacionadas a ASNs incluindo detalhes de cobrança (taxas de recuperação de manutenção) e contratos relacionados, formulários de solicitação, uma descrição adicional dos procedimentos de avaliação, práticas que a LIR solicita ASNespera-se que s adotem e informações que possam ajudar as organizações a solicitar ASNs.

Quaisquer outras diretrizes publicadas serão desenvolvidas na comunidade (quando necessário) e serão consistentes com as metas e políticas descritas neste documento.

8.0  Informações de contato de abuso

8.1  Introdução

Esta política especifica um objeto dedicado que deve ser usado como o local preferido para publicar informações de contato público de abuso na região de serviço do AFRINIC.

O objeto mencionado pode ser referenciado nos objetos inetnum, inet6num e aut-num no AFRINIC whois base de dados. Ele fornece uma maneira mais precisa e eficiente para os relatórios de abuso chegarem ao contato de rede correto.


8.2  Detalhes da política:

Para disponibilizar um novo ou usar um já existente whois objeto de banco de dados que implementa as seguintes propriedades:

  1. Uma referência única por inetnum, inet6num e aut-num
  2. Contém 2 atributos de email:
    1. "e-mail:" para comunicação pessoal
    2. "abuse-mailbox:" para manipulação automática de relatórios

O objeto deve ser acessível através do whois protocolo. AFRINIC para publicar um Documento de boas práticas que incentiva todos os membros a usar ativamente o objeto para publicar informações de contato de abuso.


8.3  Vantagens e desvantagens da política

8.3.1 Vantagens

  1. As redes poderão fornecer suas próprias informações de contato direto para os departamentos de abuso.
  2. As reclamações de abuso não serão mais enviadas para o contato "errado".
  3. Isso permite uma maior flexibilidade administrativa e operacional, e uma manipulação mais rápida do abuso será possível.

8.3.2 Desvantagens

Este objeto, como todos os outros objetos existentes, enfrentará o problema de precisão de dados. Esta política visa resolver o problema da falta de lugar para informações de contato abusivas e não vai melhorar a precisão dos dados no whois base de dados. No entanto, sugere-se à AFRINIC que ofereça uma forma de receber relatos sobre objetos que não funcionam ou não são precisos.

 

9.0  Alocações e atribuições temporárias de recursos

Em algumas circunstâncias, as organizações podem exigir recursos de IP por um determinado período de tempo, geralmente um mês ou menos. Pode ser para exposições, conferências, convenções, etc.

O AFRINIC, portanto, atribuirá recursos de numeração a entidades que requerem números IP temporários por um período fixo de tempo. Neste documento, "recursos de IP" refere-se ao unicast IPv4/ v6 endereços e números AS.


9.1  Documentando a atividade temporária

A atividade que requer recursos temporários de IP deve ser publicamente documentada e disponível, de preferência em um site. Espera-se que as entidades que requerem esses recursos de IP demonstrem que, quando a atividade ou experiência para a qual eles exigem os recursos de IP terminar, os recursos de IP serão retornados ao AFRINIC.

Um "documento publicamente acessível" é um documento que está disponível pública e aberta de forma gratuita e sem restrições de divulgação.

A AFRINIC não reconhecerá nenhuma atividade sob esta política se tal atividade não puder ser divulgada publicamente.


9.2  Atribuições de recursos IP

Os recursos são atribuídos com base no arrendamento por um período de um mês. A atribuição pode ser renovada mediante solicitação à AFRINIC, fornecendo as informações necessárias. O tamanho do recurso IP atribuído será determinado a partir do plano enviado pela entidade solicitante.

9.2.1 Documentação necessária:

A organização solicitante deve entrar em contato com a AFRINIC com as seguintes informações:

  1. Detalhes da organização: nome da organização jurídica, país onde está registrado, endereço postal, endereço físico, números de telefone e fax, site (é obrigatório).
  2. Detalhes da atividade que exige a atribuição temporária: site que detalha a atividade ou site com um link para atividades anteriores semelhantes, links de outros sites (relevantes) sobre essa atividade e a data em que a atividade acima termina.
  3. O uso planejado desses recursos de IP: Liste o tamanho da sub-rede necessário e para o que ele será usado, além de quaisquer números AS e delegação reversa, se necessário.
  4. A data pretendida de retorno dos recursos IP acima.

9.3  Taxas administrativas

A AFRINIC pode cobrar taxas administrativas (se necessário) pela atribuição dos números IP temporários acima.

10.0  Delegação reversa

Esta seção descreve a política de delegação reversa de IPv4 ao mesmo tempo que IPv6 atribuições e alocações na região de serviço do AFRINIC. Observe que o AFRINIC registra apenas delegações reversas e não está envolvido no sistema de registro de nomes de domínio.


10.1  Introdução

O AFRINIC fornece suporte para permitir que aplicativos sejam mapeados para um nome de domínio a partir de um endereço IP. A delegação reversa é obtida pelo uso do in-addr.arpa (IPv4) e ip6.arpa (IPv6) domínios.


10.2  Obtendo delegação de uma subzona in-addr.arpa

O AFRINIC aceita apenas solicitações de delegação reversa sob in-addr.arpa dos LIRs ativos do AFRINIC. Os usuários finais devem enviar suas solicitações ao LIR a partir do qual obtiveram os endereços, ou no caso de endereços independentes de fornecedor, para qualquer um dos LIRs de sua escolha. O AFRINIC executará testes para garantir que o servidor de nomes da zona em que a delegação reversa está sendo solicitada esteja ativo e configurado conforme as recomendações da RFC1912.


10.3  Delegação reversa para o espaço de endereço agregável do provedor (PA)

O AFRINIC fará delegações apenas nos limites de 8 bits (/ 16 ou / 24). Várias delegações podem ser solicitadas para cobrir prefixos do CIDR em blocos menores que a / 24.


10.4  Delegação reversa para espaço de endereço independente de provedor (PI)

O AFRINIC delegará inversamente uma zona no in-addr.arpa para um Usuário final ao qual foi atribuído espaço PI.

Para delegações de blocos de endereços menores que a / 24, será utilizado o método descrito em "Delegação IN-ADDR.ARPA sem classe" [RFC 2317].


10.5  Validade da delegação reversa

10.5.1 O AFRINIC aceita solicitações de delegação e modificações de delegações de LIRs com status de associação atualizado.

10.5.2 Nenhum serviço DNS reverso ausente das atribuições registradas:

  1. Nenhuma delegação reversa de espaço de endereço IP administrado / alocado é permitida, a menos que uma atribuição ou subalocação da alocação de endereço específica seja registrada apropriadamente no AFRINIC whois base de dados. 
  2. Para uma delegação reversa / 24, pelo menos uma atribuição ou subalocação deve ser registrada no banco de dados AFRINIC para esse / 24 específico. O / 24 inteiro não precisa ser atribuído para que a delegação reversa seja permitida.

10.6 IPv6 Delegação Reversa

Foi alcançado um consenso da IETF de que o domínio ip6.arpa é usado para um endereço no mapeamento de nomes DNS para o IPv6 espaço de endereço. Referir-se RFC2874 ao mesmo tempo que RFC3596.

A delegação do domínio ip6.arpa é feita pela IANA (Internet Assigned Numbers Authority). Os nomes dentro desta zona são delegados aos Registros Regionais da Internet, de acordo com a respectiva delegação de IPv6 espaço de endereço.


10.7 Remoção de delegações 'coxas'

Depois que um determinado atributo 'nserver' for determinado como coxo para um determinado domínio, e tentativas razoáveis ​​forem feitas para entrar em contato com as pessoas responsáveis, o atributo nserver deverá ser removido do objeto de domínio especificado. Uma linha de 'observações' deve ser adicionada ao objeto de domínio no banco de dados que está registrando isso.

No caso de todos os registros do servidor de nomes serem coxos para uma determinada delegação, o objeto do domínio seria removido na sua totalidade. Informações históricas sobre objetos de domínio removidos devem ser arquivadas por um período de tempo razoável e disponibilizadas conforme necessário.

11.0  Reservas de recursos para pontos de troca na Internet

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


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


11.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. As 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. 


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


11.4 Detalhe da política

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 rede local de IXP peering 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. 


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

 

12.0  Atribuições de Recurso Anycast

Esta política permite que uma organização receba um IPv4/IPv6 alocação ou atribuição e um Número AS puramente para uso de anycast ou GPRS Roaming Exchange (GRX).


12.1 Resumo

Esta política permite o uso de:

  1. Um (1) / 24 de IPv4 para serviços anycast de uma alocação PA de um LIR ou de uma atribuição direta do usuário final.
  2. Um / 48 de IPv6 para serviços anycast de um IPv6 Alocação de LIR ou atribuição direta do usuário final.
  3. Um número AS para fins de anycast.

A equipe da AFRINIC considerará anycast IPv4/IPv6 blocos designados para serem "totalmente utilizados" pelo LIR ao considerar a utilização para a primeira alocação ou para uma alocação adicional a um LIR.


12.2 Declaração de política

12.2.1 Uma organização pode obter um (1) / 24 IPv4 e / ou um (1) / 48 IPv6 prefixo para fins de anycast ou GRX de uma alocação ou de uma atribuição direta ao usuário final emitida pelo AFRINIC.

Um número AS também deve ser emitido para os mesmos fins, se solicitado. Esses recursos devem ser usados ​​com o único objetivo de fornecer serviços anycast. Estes IPv4/IPv6 os prefixos serão contados como totalmente utilizados quando uma organização solicitar recursos adicionais. Os critérios de utilização que se aplicam a todos IPv4 ao mesmo tempo que IPv6 as solicitações iniciais de alocação ou atribuição serão dispensadas de qualquer solicitação de atribuição de transmissão.

12.2.2 Blocos usados ​​para serviços anycast não podem ser posteriormente atribuídos ou subalocados.

Eles devem ser marcados com o atributo de status no AFRINIC whois serviço como "ASSIGNED ANYCAST".

 

Última modificação em -
Data e hora nas Maurícias -