Publicado originalmente no blog Infoblox em 22 de fevereiro de 2024
No meu blog intitulado Um /48 para cada site e para cada site um /48 (Partes 1 e 2, em inglês), o próprio título tenta capturar e resumir um princípio geral, mas crítico, do planejamento dos endereços IPv6: ao criar um plano de endereços, designar pelo menos um /48 para cada site. Mas será que um /48 para cada site é sempre suficiente? E se não, qual seria o tamanho suficiente de prefixo e como a designação de um prefixo maior impactaria o plano de endereços em geral?
Para recapitular brevemente, lembre-se de que, para a maioria dos engenheiros e arquitetos de redes, a palavra “site” tem associações muito tangíveis com a localização física de redes específicas: centros de dados, campus com redes LAN, escritórios remotos, etc. Como as redes em cada uma dessas localizações variam em tamanho e número de usuários que suportam, é natural tentar categorizá-las com base nessas características: por exemplo, pequeno, médio, grande, extragrande. Acontece que a escassez de endereços IPv4 torna tal categorização essencial. O prefixo ou prefixos IPv4 disponíveis para designar a um site podem ser poucos e de tamanho limitado. Por causa disso, um pequeno escritório remoto poderia precisar apenas de um /28 do IPv4, enquanto que a LAN de um campus central poderia exigir um /20. Se tivermos muita sorte, nossos sites pequenos, médios, grandes e extragrandes poderiam pelo menos ter prefixos de tamanho consistente e disponíveis o suficiente para cada categoria de tamanho. Por exemplo:
Tamanho do site
Prefixo IPv4 designado
Endereços IPv4
Pequeno
/28
16
Médio
/24
256
Grande
/20
4096
Extragrande
/16
65536
Mas, sendo realistas, a disponibilidade de espaço de endereço IP privado (ou seja, RFC 1918) é tão limitada na maioria das empresas que mesmo essa consistência mínima é muitas vezes impossível. O resultado são prefixos de diferentes comprimentos que são difíceis, se não impossíveis, de resumir facilmente para o roteamento ou para permitir a simplificação das listas de controle de acesso (ACL) de segurança.
Em comparação, a abundância geral do IPv6 permite a designação de um prefixo IPv6 de tamanho consistente, ou “tamanho único”, para um site (por exemplo, /48 ou maior), independentemente do tamanho físico do site, o diâmetro das redes, o número de usuários, etc. A uniformidade dessas designações para os sites torna a sumarização de roteamento e a simplificação das ACL muito mais fáceis. Essa consistência também pode simplificar ainda mais a administração e a operação das redes –principalmente considerando que o tamanho recomendado do prefixo IPv6 deveria sempre estar alinhado a nibble. A parte de um prefixo alinhado a nibble exclusiva de uma rede pode ser usada para identificar o site com mais facilidade, ajudando na administração ou resolução de problemas na rede.
No meu artigoMétodos de alocação de prefixos IPv6(Partes 1 e 2, em inglês) descrevo os métodos mais típicos para designar prefixos a partir de uma alocação maior. Destes, demonstraremos primeiro o método de designação do seguinte prefixo disponível e suas limitações. O gráfico a seguir descreve um plano de endereços inicial com designações de /48 por site. Cada prefixo é designado sequencialmente a partir de um /44 que fornece até 16 sites no total.
(Acesso livre, não requer assinatura)
Observe que no exemplo, esse total de prefixos disponíveis diminui para 15 porque pulamos o uso do primeiro prefixo disponível de 2001:db8:1000::/48. Isso é feito para alinhar o número do site com a numeração do prefixo (por exemplo, Site 1 = 2001:db8:1001::/48, Site 2 = 2001:db8:1002::/48). Isso também pode ajudar a evitar confundir dois prefixos que parecem idênticos devido às regras de compactação zero dos endereços IPv6, mas que possuem comprimentos CIDR diferentes (por exemplo, 2001:db8:1000::/44 e 2001:db8:1000::/48).
Mas o que deveria acontecer quando um site cresce ou muda de uma forma que requer espaço de IPv6 adicional? E como podemos então planejar fornecer espaço de prefixo adicional e, ao mesmo tempo, manter as práticas de planejamento que proporcionam os maiores benefícios operacionais? Não gostaríamos de ter que renumerar nosso site para tentar estender o uso do único prefixo /48 designado, principalmente quando uma alocação geral suficientemente grande deveria fornecer /48 suficientes para permitir a adição de um ou mais prefixos a um site existente. Mas se não planejarmos, é possível que os /48 adicionais para um site não sejam contíguos à alocação inicial do site /48. Essa falta de contiguidade não é necessariamente o fim do mundo, mas pode resultar em uma maior (e mais precoce) desagregação do espaço de endereços IPv6 dentro da rede. Ser sempre capaz de identificar um site por meio de um único prefixo resumido na tabela de roteamento e que tem um único limite de segurança (e uma entrada ACL associada) proporciona benefícios operacionais e administrativos claros.
Uma forma de garantir que /48 contíguos estejam disponíveis é reservá-los com antecedência, de preferência ao mesmo tempo em que o plano de endereços inicial é definido. Mas quantos /48 adicionais deveriam ser reservados por site? O limite inferior é obviamente um /48 adicional. Qualquer prefixo /48 adicional reservado até o primeiro nibble só poderia ser resumido ao longo de um limite que não seja um nibble. Mas qualquer tentativa de adicionar /48 adicionais somente quando cada site precisar deles e, depois resumir tanto quanto possível, resultará em uma coleção de prefixos diferentes resumidos para sites diferentes. Esses prefixos resumidos não seriam tão legíveis em uma tabela de roteamento quanto um único prefixo alinhado ao nibble para cada site.
Observe que no exemplo, esse total de prefixos disponíveis diminui para 15 porque pulamos o uso do primeiro prefixo disponível de 2001:db8:1000::/48. Isso é feito para alinhar o número do site com a numeração do prefixo (por exemplo, Site 1 = 2001:db8:1001::/48, Site 2 = 2001:db8:1002::/48). Isso também pode ajudar a evitar confundir dois prefixos que parecem idênticos devido às regras de compactação zero dos endereços IPv6, mas que possuem comprimentos CIDR diferentes (por exemplo, 2001:db8:1000::/44 e 2001:db8:1000::/48).
Mas o que deveria acontecer quando um site cresce ou muda de uma forma que requer espaço de IPv6 adicional? E como podemos então planejar fornecer espaço de prefixo adicional e, ao mesmo tempo, manter as práticas de planejamento que proporcionam os maiores benefícios operacionais? Não gostaríamos de ter que renumerar nosso site para tentar estender o uso do único prefixo /48 designado, principalmente quando uma alocação geral suficientemente grande deveria fornecer /48 suficientes para permitir a adição de um ou mais prefixos a um site existente. Mas se não planejarmos, é possível que os /48 adicionais para um site não sejam contíguos à alocação inicial do site /48. Essa falta de contiguidade não é necessariamente o fim do mundo, mas pode resultar em uma maior (e mais precoce) desagregação do espaço de endereços IPv6 dentro da rede. Ser sempre capaz de identificar um site por meio de um único prefixo resumido na tabela de roteamento e que tem um único limite de segurança (e uma entrada ACL associada) proporciona benefícios operacionais e administrativos claros.
Uma forma de garantir que /48 contíguos estejam disponíveis é reservá-los com antecedência, de preferência ao mesmo tempo em que o plano de endereços inicial é definido. Mas quantos /48 adicionais deveriam ser reservados por site? O limite inferior é obviamente um /48 adicional. Qualquer prefixo /48 adicional reservado até o primeiro nibble só poderia ser resumido ao longo de um limite que não seja um nibble. Mas qualquer tentativa de adicionar /48 adicionais somente quando cada site precisar deles e, depois resumir tanto quanto possível, resultará em uma coleção de prefixos diferentes resumidos para sites diferentes. Esses prefixos resumidos não seriam tão legíveis em uma tabela de roteamento quanto um único prefixo alinhado ao nibble para cada site.
Para demonstrar isso melhor, o gráfico a seguir mostra um exemplo de designações futuras de prefixos /48 para os nossos sites originais segundo o método de alocação do seguinte prefixo disponível. O Site 4 é o primeiro a solicitar espaço IPv6 adicional (por exemplo, para uma rede de sobreposição fora de banda (OOB)) e recebe o seguinte prefixo disponível de 2001:db8:1004::/48. Mais tarde ainda, o Site 4 adiciona um centro de dados que precisará de seu próprio /48 e o seguinte prefixo disponível de 2001:db8:1005::/48 é designado. O Site 1 descobre a rede de sobreposição OOB que implementou o Site 4 e quer fazer a mesma coisa. Portanto, é designado a eles o seguinte prefixo disponível de 2001:db8:1006::/48. A mesma coisa acontece com o Site 3: É designado a eles o seguinte prefixo disponível de 2001:db8:1007::/48. Agora o Site 4 percebe que precisa adicionar outro centro de dados, mas desta vez com mais suporte para múltiplos clientes, portanto os seguintes dois prefixos disponíveis são designados: 2001:db8:1008::/48 e 2001:db8:1009::/48. Como resultado dessas solicitações assíncronas de prefixos IPv6 atendidas pela designação do seguinte prefixo disponível, a tabela de roteamento e/ou as entradas de ACL são um pouco confusas (e provavelmente se tornarão mais confusas ao aplicar novamente este método).
Então, se for melhor usar um único prefixo alinhado ao nibble, qual deveria ser este prefixo? Para responder esta pergunta, poderia ser útil pensar em qual poderia ser o
limite superior razoável para o número de /48 adicionais por site. Leve em conta que este seria o limite superior para o maior dos nossos sites em geral (qualquer seja o seu tamanho, todos os outros sites receberão a mesma designação que o site maior). O seguinte maior prefixo alinhado ao nibble é um /44, que fornece 16 prefixos /48 no total: um /48 inicial designado ao site e 15 prefixos /48 que são mantidos em reserva. Um /40 forneceria 256 prefixos /48 (ou 255 prefixos /48 mantidos na reserva). Um /36 proporcionaria uma reserva de 4095 /48.
Então, qual dos prefixos maiores alinhados ao nibble deveríamos selecionar para nosso site maior? A realidade é que é difícil, senão impossível, saber antecipadamente quanto espaço de prefixo adicional pode ser necessário e/ou resultar útil. Devemos ter em mente que, quanto mais prefixos mantivermos em reserva para cada site, mais consumiremos da nossa alocação geral. Isto pode reduzir a capacidade de criar uma estrutura adicional no topo do nosso plano de endereços. Por exemplo, talvez precisemos ter prefixos suficientes para permitir o resumo regional em um limite de nibble para um prefixo que resume sites. Ou talvez precisemos manter em reserva prefixos alinhados ao nibble para uso futuro no nível superior do plano de endereços (por exemplo, os primeiros 16 prefixos alinhados ao nibble derivados da alocação geral do IPv6). Mas, por enquanto, vamos continuar a nos concentrar na questão de como dimensionar melhor as designações do nosso site.
O gráfico a seguir mostra um resultado alternativo e mais ideal com base no nosso exemplo anterior. Em vez de designar inicialmente apenas um /48 por site, é alocado um /44 por site. Para este exemplo, a equipe de rede não prevê a adição de mais de 16 sites no total na Região 1, portanto, é alocado a ela um /40 do qual é tomado o prefixo /44 por site. Agora, quando cada um dos sites exigir prefixos /48 adicionais –para qualquer finalidade– haverá até 15 prefixos adicionais disponíveis. Esses prefixos /48 adicionais por site sempre serão resumidos como um /44 para a Região 1, e a Região 1 resumirá estes upstream como um /40.
Observe que a designação regional de /40 mostrada acima é apenas para mostrar um resumo alinhado ao nibble dos prefixos /44 do site. Baseia-se na suposição de que a rede do exemplo já considera benéfico gerenciar a rede usando uma topologia baseada em localização geográfica. Do outro lado, algumas redes são grandes o suficiente para que um único site possa se beneficiar da alocação de um /40 para esse site, seguida por uma ou mais designações iniciais de /48. Nesse caso, qualquer resumo regional desejado poderia idealmente ocorrer no próximo maior limite de nibble de um /36.
Independentemente disso, é evidente que o uso deste método de alocação dispersa para designação de sites dentro da empresa pode resultar na necessidade de uma alocação de IPv6 maior. Isto é especialmente verdadeiro quando são seguidas as melhores práticas de planejamento de endereços consistentes em manter um alinhamento estrito ao nibble para as designações de prefixos IPv6. Muitas empresas que já obtiveram alocações do IPv6 podem perceber que o tamanho dessas designações não suportará simultaneamente uma alocação dispersa para designações a sites e/ou um alinhamento ao nibble estrito dos prefixos IPv6.
Felizmente, obter uma alocação maior de qualquer um dos cinco Registros Regionais da Internet (RIR) que correspondam a sua principal região operacional é um processo relativamente fácil e econômico. Lembre-se de que quaisquer que sejam os requisitos da rede local para o espaço de endereços IPv6, também precisará considerar suas necessidades atuais e planejadas de implantação na nuvem (tal vez usando BYOIPv6). Poderia ser desejável, por motivos de segurança (ou mesmo apenas por facilidade administrativa), manter um ou mais espaços de endereços fora do (mas talvez em paralelo com) seu espaço de endereços IPv6 local. E não se esqueça de considerar as redes futuras adicionadas devido às fusões e aquisições. Embora seja sempre possível obter espaço adicional de endereços IPv6, as alocações futuras provavelmente não serão contíguas à sua alocação inicial e podem aumentar os riscos de ter que renumerar. Isso é especialmente certo se estiver tentando “se contentar” com sua alocação inicial do IPv6 obtida anos atrás.
*Repostado com permissão, cortesia de Infoblox”
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.
