Eliminar a obrigação de os solicitantes devolverem os endereços designados por seus provedores uma vez que obtém uma designação direta

Idioma Original Español Data Publicação 29/10/2019 Última Modificação 28/10/2019
Período de últimos comentários Não aplicável Data de ratificação Não aplicável Data de implementação Não aplicável
Estado Em discussão Baixar TXT PDF XML DOCX
Ver outras versões 1.0 (comparar)

Autores

Nome: Edmundo Cazarez-Lopez
E-mail: edmundo.cazarez@nic.mx
Organização: NIC Mexico

Dados da Proposta

Tipo Política: LACNIC
Id: LAC-2019-10
Última versão: 1

Resumo

A presente proposta visa eliminar a obrigação de os solicitantes devolverem os endereços designados por seus provedores uma vez que obtém uma designação direta, dado que o trabalho decorrente do cumprimento da obrigação implica interromper a operação da rede e da prestação de serviços a seus clientes, ainda mais, quando o número de endereços designados diretamente for menor que o número de endereços que têm em uso e devem devolver para seus provedores.

Justificativa

Existem casos documentados de solicitantes para os que essa obrigação não faz sentido, dada a quantidade de trabalho envolvida em refazer suas redes com a nova numeração e o número de endereços que atualmente eles têm em uso. Em alguns casos, o número de endereços que têm em uso é maior que o /22 máximo que pode ser designado a eles. Em muitas ocasiões, essa obrigação faz com que os candidatos desistam e abandonem o pedido.

Texto

Modificações dos pontos 2.3.3.1.1, 2.3.3.1.2 e 2.3.3.4.3.:

---- Texto Atual: ----

2.3.3.1.1. - Requisitos para um prefixo /24 a um /22

Para qualificar para a alocação de um prefixo /24 a um /22, o ISP solicitante deverá cumprir os seguintes requisitos:

1. Demonstrar o uso ou a necessidade imediata de pelo menos 25% do prefixo solicitado.

2. Entregar um plano detalhado de uso de 50% do uso do prefixo solicitado para um ano.

- Se anteriormente existia um bloco designado por um provedor, e quiser que seja mantido o mesmo bloco para evitar a renumeração, e há concordância entre ambas as partes, esse bloco poderá ser traspassado [1] (com a mudança de titularidade no WHOIS, através do LACNIC).

- Se espaço adicional foi justificado e a sua alocação for possível, o receptor poderá decidir se o traspasso é conveniente para ele e recebe um bloco pelo espaço adicional, ou prefere um único bloco pelo total e, portanto, renumera. No caso de renumeração, o bloco previamente designado deverá ser devolvido no prazo máximo de 12 meses. Excepcionalmente, este prazo pode ser prorrogado por mais 6 meses se for justificado que não houve tempo para a obtenção dos recursos necessários e a renumeração correspondente.

- Caso o solicitante ainda não conte com um bloco IPv6 designado por LACNIC, solicitar ao mesmo tempo um bloco IPv6 cumprindo a política aplicável.

2.3.3.1.2. - Requisitos para um prefixo /21 ou menor (bloco de 8/24 ou mais)

Se o ISP solicitante requerer uma alocação inicial de endereços IPv4 a partir de um prefixo /21, deverá atender aos seguintes requisitos:

- Fornecer informações sobre as designações feitas por prefixos de tamanho /29 ou menores (mais de 8 endereços IPv4) no WHOIS do LACNIC

- Fornecer documentação justificando a alocação de espaço de endereços inicial. (Preenchimento do formulário de pedido de endereços IPv4 para ISP). Informações detalhadas deverão ser incluídas, mostrando como esse recurso será usado dentro dos períodos de três, seis e doze meses.

- Se anteriormente existia um bloco designado por um provedor, e quiser que seja mantido o mesmo bloco para evitar a renumeração, e há concordância entre ambas as partes, esse bloco poderá ser traspassado [2] (com a mudança de titularidade no WHOIS, através do LACNIC).

- Se espaço adicional foi justificado e a sua alocação for possível, o receptor poderá decidir se o traspasso é conveniente para ele e recebe um bloco pelo espaço adicional, ou prefere um único bloco pelo total e, portanto, renumera. No caso de renumeração, o bloco previamente designado deverá ser devolvido no prazo máximo de 12 meses. Excepcionalmente, este prazo pode ser prorrogado por mais 6 meses se for justificado que não houve tempo para a obtenção dos recursos necessários e a renumeração correspondente.

- Caso o solicitante ainda não conte com um bloco IPv6 designado por LACNIC, solicitar ao mesmo tempo um bloco IPv6 cumprindo a política aplicável.

...

2.3.3.4.3 - Tamanho da designação e procedimento.

O solicitante deve justificar que irá anunciar o espaço designado, com seu próprio sistema autônomo, pelo menos para outro sistema autônomo.

O tamanho da designação mínima de endereços IPv4 para um usuário final é de um bloco com prefixo /24 e o tamanho máximo será um /20, o qual deverá ser justificado, de acordo com a taxa de utilização (seção 2.3.3.4.2).

Se previamente havia um bloco designado por um provedor, e pretende-se manter o mesmo para evitar a renumeração, e há acordo entre ambas as partes, esse bloco poderá ser transferido (com as alterações correspondentes no whois). Se foi justificado espaço adicional e a sua designação for possível, o receptor poderá decidir se o traspasso é conveniente para ele e recebe um bloco pelo espaço adicional, ou prefere um único bloco pelo total e, portanto, renumera. No caso de renumeração, o bloco previamente designado deverá ser devolvido no prazo máximo de 6 meses. Excepcionalmente, este prazo pode ser prorrogado por mais 6 meses se for justificado que não houve tempo para a obtenção dos recursos necessários e a renumeração correspondente.

Para designações adicionais, serão seguidas as políticas incluídas na seção 2.3.4 aplicáveis aos usuários finais.

---- Texto Proposto: ----

2.3.3.1.1. - Requisitos para um prefixo /24 a um /22

Para qualificar para a alocação de um prefixo /24 a um /22, o ISP solicitante deverá cumprir os seguintes requisitos:

1. Demonstrar o uso ou a necessidade imediata de pelo menos 25% do prefixo solicitado.

2. Entregar um plano detalhado de uso de 50% do uso do prefixo solicitado para um ano.

- Caso o solicitante ainda não conte com um bloco IPv6 designado por LACNIC, solicitar ao mesmo tempo um bloco IPv6 cumprindo a política aplicável.

2.3.3.1.2. - Requisitos para um prefixo /21 ou menor (bloco de 8/24 ou mais)

Se o ISP solicitante requerer uma alocação inicial de endereços IPv4 a partir de um prefixo /21, deverá atender aos seguintes requisitos:

- Fornecer informações sobre as designações feitas por prefixos de tamanho /29 ou menores (mais de 8 endereços IPv4) no WHOIS do LACNIC

- Fornecer documentação justificando a alocação de espaço de endereços inicial. (Preenchimento do formulário de pedido de endereços IPv4 para ISP). Informações detalhadas deverão ser incluídas, mostrando como esse recurso será usado dentro dos períodos de três, seis e doze meses.

- Caso o solicitante ainda não conte com um bloco IPv6 designado por LACNIC, solicitar ao mesmo tempo um bloco IPv6 cumprindo a política aplicável.

...

2.3.3.4.3 - Tamanho da designação.

O solicitante deve justificar que irá anunciar o espaço designado, com seu próprio sistema autônomo, pelo menos para outro sistema autônomo.

O tamanho da designação mínima de endereços IPv4 para um usuário final é de um bloco com prefixo /24 e o tamanho máximo será um /20, o qual deverá ser justificado, de acordo com a taxa de utilização (seção 2.3.3.4.2).

Para designações adicionais, serão seguidas as políticas incluídas na seção 2.3.4 aplicáveis aos usuários finais.

Informações Adicionais

-

Tempo de Implementação

O tempo de implementação desta proposta é imediato, uma vez que alcance consenso e seja ratificada pela Diretoria.

Referências

-

Notas Públicas da equipe de LACNIC

ANALISE DE IMPACTO PELA EQUIPE DE LACNIC - Proposta LAC-2019-10 - versión 1

Interpretación de la propuesta por el staff de LACNIC
----------------------------------------------------

Aplicación de la propuesta
--------------------------
Esta propuesta se aplicaría a los casos de distribución inicial IPv4 a ISPs y a usuarios finales.

Modificación del texto actual
---------------------------
Se modifican las secciones del manual de políticas: 2.3.3.1.1, 2.3.3.1.2 y 2.3.3.4.3, donde se elimina el texto:
“- Si previamente había un bloque asignado por un proveedor, y se desea mantener el mismo para evitar la renumeración, y hay acuerdo entre ambas partes, se podrá ceder[1] dicho bloque (con el cambio de titularidad en el whois, a través de LACNIC).

- Si se ha justificado espacio adicional y es posible su distribución, el receptor podrá decidir si la cesión le es conveniente y recibe un bloque por el espacio adicional o prefiere un único bloque por el total y, por lo tanto, renumera. En caso de renumeración, el bloque previamente asignado deberá ser retornado en un plazo máximo de 12 meses. Excepcionalmente, este plazo podrá ser extendido en 6 meses adicionales si se justifica que no ha habido tiempo para la consecución de los recursos que precisa y la renumeración correspondiente.”

Comentarios del staff
---------------------
(Los comentarios son observaciones para ayudar a diferenciar los cambios que presenta la propuesta con respecto al texto actual del Manual de Políticas)

1. La propuesta elimina el requerimiento de devolver el bloque IPv4 perteneciente al proveedor cuando reciba un bloque asignado directamente de LACNIC, tanto para ISPs como para usuarios finales.

Impacto en el sistema de registro
----------------------------------
Esta propuesta no implicaría cambios en los sistemas de LACNIC.

Fuentes oficiales de referencias
--------------------------------
Contexto: situación en otros RIRs

- AFRINIC, APNIC, ARIN y RIPE
No tienen un requisito de devolver las direcciones que tengan asignadas por sus proveedores una vez que obtienen una asignación directa.

- APNIC
En la región APNIC, las políticas requieren justificar la necesidad al momento de solicitar los recursos. Sin embargo, una vez delegado el espacio no hay políticas que especifiquen cómo utilizan sus recursos en su propia red.

- ARIN
El requisito de renumeración existía previamente, pero se ha eliminado.

- RIPE
La posición general de la Comunidad RIPE es que el registro de recursos no debe mezclarse con las decisiones sobre cómo operar una red.

Política de privacidade