Summary

  • A seção 4.2.3.6 do manual vigente da ARIN considera a necessidade de multihoming suficiente para justificar um /24 fornecido por um ISP a um cliente a jusante. O cliente entrega os contatos de todos os provedores e usa roteamento de borda com o fornecedor do bloco. Somente um provedor pode fornecer o /24 sob essa justificativa sem provas extras.
  • A seção 2.7 define multihoming como conectividade contínua de mais de um ISP e pelo menos um prefixo anunciado por dois deles. A seção 4.2.3.3 recomenda devolver os endereços ao sair de um ISP e renumerar no espaço do novo; o antigo deve conceder tempo suficiente.
  • A política original de 2001, adotada e implementada em 2002, permitia justificar o /24 pela necessidade de multihoming independentemente da contagem de hosts. O manual atual determina a regra presente.

Uma segunda operadora resolve a falha de um caminho. Ela não transforma automaticamente um bloco em espaço independente do primeiro provedor. A definição da ARIN requer conexão contínua a mais de um ISP e pelo menos um prefixo anunciado por dois fornecedores. Comprar um circuito reserva sem colocá-lo nessa relação de roteamento ainda não satisfaz toda a descrição.

O benefício está na seção 4.2.3.6. O cliente pode apresentar a necessidade de multihoming como justificativa suficiente para receber um /24. A regra está no capítulo de reatribuições e realocações feitas por ISPs a clientes; não descreve a entrega direta pela ARIN de um bloco independente do provedor. Quem fornece o /24 recebe os dados de contato de todos os outros fornecedores do cliente. Entre o cliente e esse ISP deve funcionar um protocolo de roteamento de borda.

A frase seguinte fecha a conta: o cliente pode receber um /24 de apenas um de seus fornecedores por essa regra sem justificação adicional. O segundo ISP pode carregar tráfego e anunciar o prefixo, mas a mesma alegação de multihoming não rende automaticamente outro /24. Dois caminhos de acesso não dão dois cupons de endereços.

O ISP fornecedor também precisa ser capaz de explicar a alocação. Pode apresentar à ARIN as informações coletadas do cliente ou indicar seu número de sistema autônomo. A seção 4.2.3.7 exige demonstração de uso eficiente, inclusive históricos de atribuição; a seção 4.2.3.7.1 manda registrar reatribuições IPv4 de /29 ou maiores em SWIP ou serviço de diretório equivalente. O /24 fica na trilha documental do espaço do provedor.

A política de 2001 revela o problema original. A exigência de mais de uma rota podia demandar um prefixo /24 mesmo quando os critérios de quantidade de dispositivos não o justificassem. ARIN aceitou essa necessidade técnica como motivo próprio. Já exigia contatos de todos os provedores e limitava o benefício a um deles. A solução para a arquitetura de rede nasceu vinculada a uma fonte de endereços.

O vínculo importa quando a relação comercial acaba. A seção 4.2.3.3 desencoraja fragmentar blocos contíguos do ISP e incentiva a devolução de endereços por clientes que mudam de provedor. Recomenda devolver o espaço antigo e renumerar dentro do espaço do novo ISP. O fornecedor anterior deve permitir tempo suficiente. O manual não fixa um prazo em dias nem transforma cada troca em uma ordem universal de devolução. As partes precisam planejar a engenharia da saída.

Uma empresa pode ter dois links ativos e um prefixo anunciado pelos dois. Isso fortalece a continuidade diante de uma falha de conexão. O /24 obtido de um deles permanece em uma relação de registro com esse fornecedor. Numa mudança, DNS, listas de permissão, regras de firewall, filtros de rota e serviços expostos no bloco entram na conta de renumeração. A contratação de redundância deveria trazer uma coluna para esse custo futuro.

Os documentos oficiais não identificam um cliente que tenha usado essa cláusula e depois calculado o custo de trocar de provedor. Uma reatribuição datada e o cronograma da migração preencheriam essa lacuna. A regra já é clara: dois caminhos podem anunciar a rota, mas a justificativa simplificada fornece um /24 por meio de um único ISP.