| Adicionar ao carrinho |
|
1) Resumo do problema
A IANA agora esgotou seu pool de IPv4 / 8 blocos, tendo distribuído seus restantes IPv4 endereços de acordo com a "Política Global para a Alocação dos Restantes IPv4 Address Space ". [1] No entanto, há a possibilidade de que IANA receba endereços devolvidos após o esgotamento de seu pool de / 8s.
Uma proposta de política global anterior elaborada por uma equipe composta por pessoas de cada um dos cinco RIRchegou a um consenso às quatro RIRs, e foi posteriormente endossado por estes RIRs 'Boards. Na região AFRINIC, isso foi AFPUB-2009-v4-002, "Proposta de política global para a alocação de IPv4 blocos para Registros Regionais da Internet ". Para ver o número de referência da proposta para esta proposta em todos os cinco RIRs, consulte o Apêndice A.
A versão aprovada na quinta região foi substancialmente reescrita pela comunidade ARIN para atender a algumas de suas preocupações. No entanto, dada a natureza das reescritas, teria sido difícil conciliar essa versão com a versão que alcançou consenso nas outras quatro RIRs. Portanto, alguns membros da comunidade ARIN escreveram uma nova proposta global, "Política Global para IPv4 Alocações pelo IANA Post Exhaustion ", que foi adotado na região ARIN. É AFPUB-2010-v4-003-draft-02. Para ver o número de referência da proposta para esta proposta em todos os cinco RIRs, consulte o Apêndice A. No entanto, existem problemas significativos com AFPUB-2010-v4-003-draft-02. Esses são:
O pool de recuperação pode ser exaurido por RIR(s) com altas taxas de alocação após o (s) primeiro (ou primeiros) período (s) de alocação. Há duas razões principais RIRs terão taxas de alocação diferentes após o esgotamento do pool da IANA:
- Taxa de crescimento da Internet na região
- Políticas desenvolvidas por diferentes regiões que regem como a última parte de seus IPv4 endereços devem ser gerenciados.
Em resposta aos IPv4 esgotamento, algum RIR comunidades optaram por aplicar políticas a uma parte de sua última IPv4 endereços que visam auxiliar em uma transição suave para IPv6. Um efeito de tais políticas é que podem desacelerar o consumo de IPv4 endereços alocados de acordo com essas políticas. Este efeito colateral colocaria RIRs que optaram por adotar tais políticas em desvantagem, pois levarão muito mais tempo para se qualificar para o espaço sob AFPUB-2010-v4-003-draft-02 comparado com RIRs que optaram por não adotar tais políticas. Portanto, para garantir que a variação regional na política de runout entre RIRs é contabilizado, é importante ter um método de redistribuição da IANA que possa continuar a fornecer recursos para RIRs em mais de um (ou apenas alguns) períodos de alocação.
- As definições de quando um RIR é considerado "esgotado" e, portanto, elegível para espaço da IANA, deve ser mais flexível, dado o muito diferente RIR ambientes de política e o número de endereços disponíveis a qualquer momento.
- De acordo com a fórmula de redistribuição proposta em AFPUB-2010-v4-003-draft-02, é possível para um RIR ser o único elegível RIR no primeiro período de alocação da IANA e para esse RIR para reivindicar todo o pool de recuperação. Também é possível que apenas um RIR poderia ser elegível durante os períodos de alocação subsequentes e obter o pool total da IANA disponível naquele momento.
Para evitar que isso aconteça, é melhor ter uma fórmula que permita RIRs levar apenas uma determinada fração do pool da IANA em cada período de alocação.
Um problema com ambos AFPUB-2009-v4-002 e AFPUB-2010-v4-003-draft-02 está relacionado com a política de devolução de endereços pelo RIRs para IANA:
- Em AFPUB-2009-v4-002, a devolução de endereços para o pool de recuperação era obrigatória. Essa restrição era uma preocupação significativa para a comunidade ARIN.
- Em AFPUB-2010-v4-003-draft-02, devolução de endereços por RIRs é opcional, mas não há nada que impeça um RIR o que não contribuiu em nada para o pool de devolução da IANA ao reivindicar parte, ou mesmo a totalidade, do pool de devolução.
2) Resumo de como esta política trata o problema
Esta política descreve o processo que IANA seguirá para alocar IPv4 recursos para Registros Regionais de Internet (RIRs) após o esgotamento do pool central de endereços.
Os processos de como IPv4 espaço pode ser colocado no IANA recuperado IPv4 Pool está fora do escopo desta proposta.
- Por causa dos dois problemas acima, esta nova proposta separa a devolução do espaço de endereçamento para IANA da redistribuição desse espaço pela IANA. Em vez disso, os autores desta nova proposta tratam o retorno e a redistribuição como duas questões distintas que deveriam ser tratadas como políticas distintas.
Um problema com AFPUB-2009-v4-002, AFPUB-2010-v4-003-draft-02e a primeira versão do AFPUB-2011-v4-004-draft-01 é que tenta encontrar maneiras de fazer "elegibilidade" e "exaustão" atender às diferentes necessidades de todos os cinco RIRs causou problemas para pelo menos dos RIRs.
- Para evitar essa situação, esta segunda versão do AFPUB-2011-v4-004-draft-01 invoca o precedente da última política global para IPv4 distribuição pela IANA [1] para propor uma forma alternativa de distribuir o espaço da IANA. Ou seja, que haja uma distribuição igual de endereços entre todos RIRs
3) Política
Após a adoção deste IPv4 política de endereço da Diretoria da ICANN, a IANA estabelecerá um IPv4 Pool a ser utilizado após RIR IPv4 exaustão, conforme definido na Seção 1. O Recuperado IPv4 O pool inicialmente conterá quaisquer fragmentos que possam sobrar na IANA. Também conterá qualquer espaço devolvido à IANA por qualquer outro meio.
3.1) Recuperado IPv4 Piscina:
O recuperado IPv4 O pool será administrado pela IANA. Ele conterá:
a) Quaisquer fragmentos remanescentes no inventário da IANA após os últimos / 8s de IPv4 espaço são delegados ao RIRs
- O inventário da IANA exclui "Uso especial IPv4 endereços "conforme definido no BCP 153 e quaisquer endereços alocados pela IANA para uso experimental.
b) Qualquer IPv4 espaço devolvido à IANA por qualquer meio.
O recuperado IPv4 A piscina ficará inativa até o primeiro RIR tem menos de um total de / 9 em seu estoque de IPv4 espaço de endereço.
Quando um dos RIRs declara que tem menos de um total de / 9 em seu inventário, o recuperado IPv4 pool será declarado ativo, e os endereços IP do recuperado IPv4 O pool será alocado conforme indicado na Seção 4.2 abaixo.
3.2) Alocação de devolvidos IPv4 espaço de endereçamento da IANA:
a) As alocações da IANA podem começar assim que o pool for declarado ativo.
b) Em cada "IPv4 período de alocação ", cada RIR receberá um único "IPv4 unidade de alocação "da IANA.
posso "IPv4 período de alocação "é definido como um período de 6 meses após 1º de março ou 1º de setembro de cada ano.
d) A IANA irá calcular o tamanho do "IPv4 unidade de alocação "nos seguintes momentos:
- Quando o recuperado IPv4 Pool é ativado primeiro
- No início de cada IPv4 período de alocação
Para calcular o "IPv4 unidade de alocação "nesses momentos, a IANA usará a seguinte fórmula:
IPv4 unidade de alocação = 1/5 do recuperado IPv4 pool, arredondado para baixo para o próximo limite CIDR (potência de 2).
Não RIR pode obter mais do que este cálculo usado para determinar o IPv4 unidade de alocação, mesmo quando podem justificar a necessidade dela.
O mínimo "IPv4 tamanho da unidade de alocação "será um / 24. Se o cálculo usado para determinar o IPv4 unidade de alocação resulta em um bloco menor que / 24, a IANA não distribuirá quaisquer endereços nesse IPv4 período de alocação.
3.3) Relatórios
A IANA pode fazer anúncios públicos de IPv4 abordar transações que ocorrem sob esta política. A IANA fará as modificações apropriadas na página "Internet Protocol V4 Address Space" do site da IANA [2] e poderá fazer anúncios em suas próprias listas de anúncios apropriadas. Os anúncios da IANA serão limitados a quais intervalos de endereços, o tempo de alocação e a qual registro eles foram alocados.
4) Prós / Contras
Vantagens:
A política fornece um mecanismo para a distribuição contínua de IPv4 espaço de endereço, ao remover as áreas de AFPUB-2009-v4-002 que eram problemáticos para a comunidade ARIN, e removendo as áreas problemáticas de AFPUB-2010-v4-003-draft-02. Ou seja, a proposta:
- Permite variação regional na política de runout entre RIRs a serem contabilizados na distribuição dos Recuperados IPv4 Piscina
- Impede a possibilidade de um único RIR sendo elegível para ser alocado todo o recuperado IPv4 Pool no primeiro (e talvez único) período de alocação
- Remove duas áreas da política que não chegaram a um acordo nas tentativas anteriores desta proposta
- Como os endereços devem ser colocados no recuperado IPv4 piscina
- Referências sobre como as transferências devem ou não ocorrer
Desvantagens:
Esta proposta não fornece detalhes de como o espaço de endereçamento pode ser devolvido ao IANA IPv4 Piscina recuperada.
5) Cronograma de implementação
Assim que o consenso for alcançado em cada um dos cinco RIR regiões, a política será encaminhada à ICANN para aprovação e então implementada pela IANA
6) Referências
- "Política Global para a Alocação dos Restantes IPv4 Espaço de Endereço " http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
- "IANA IPv4 Address Space Registry ", fevereiro de 2011 http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
7) Apêndice A
Número da proposta dado a "Proposta de política global para a alocação de IPv4 bloqueios para Registros Regionais da Internet "em cada uma das cinco regiões:
- AFRÍNICO: AFPUB-2009-v4-002
- APNIC: prop-069
- ARIN: ARIN-2009-3
- LACNIC: LAC-2009-01
- MADURO: MADURO 2009-01
Número da proposta dado à "Política Global para IPv4 Alocações pela IANA Post Exhaustion "em cada uma das cinco regiões:
- AFRÍNICO: AFPUB-2010-v4-003-draft-02
- APNIC: prop-086
- ARIN: ARIN-2010-10
- LACNIC: LAC-2010-04
- MADURO: MADURO 2010-05
| HISTÓRIA | |
| 2011-02-11 | A lista de mala direta do RPD foi informada sobre a apresentação da proposta ao ASO-AC.https://lists.AFRINIC.net/pipermail/rpd/2011/001258.html> |
| 2011-04-28 | Proposta submetida formalmente ao processo político AFRINIC.https://lists.AFRINIC.net/pipermail/rpd/2011/001481.html> |
| 2011-05-06 | Proposta postada no site AFRINIC.https://lists.AFRINIC.net/pipermail/rpd/2011/001560.html> |
| 2011-06-08 | Proposta discutida no AFRINIC-14 em Dar es Salaam e ganha consenso.https://lists.AFRINIC.net/pipermail/rpd/2011/001759.html> |
| 2011-07-29 | Última chamada começahttps://lists.AFRINIC.net/pipermail/rpd/2011/001840.html> |
| 2011-08-03 | Última chamada termina |
| 2011-09-09 | Co-presidentes do PDWG declaram consensohttps://lists.AFRINIC.net/pipermail/rpd/2011/001853.html> |
