🌞 📽️ 👨🏻‍🏫 IPv6 - você está fazendo errado ✳️ 🃏 🆕

Existem muitos conceitos errados e mitos sobre o IPv6. Freqüentemente, os provedores de hospedagem não entendem como usá-lo e pensam em abordagens desatualizadas do mundo do IPv4. Por exemplo, tendo octillions de endereços IPv6, o hoster vende endereços para clientes individualmente, em vez de alocar uma rede / 64 de pleno direito, conforme segue as recomendações.

Acontece que os hosters atribuem endereços IPv6 a diferentes clientes na mesma rede / 64. Ao mesmo tempo, serviços grandes, como o Google, percebem todos os endereços dentro do intervalo / 64 como um cliente. Como resultado, os clientes podem sofrer devido às atividades de um colega de banda.

A disponibilidade de endereços IPv6 permite atribuir endereços externos completos a recursos internos, como contêineres ou clientes VPN. Para fazer isso, o host deve fornecer ao cliente uma rede roteada separada. Infelizmente, quase ninguém pode fazer isso.

Neste artigo, analisaremos os principais erros no uso de provedores IPv6.

História: RFC 3177

Em 2001, as recomendações sobre a alocação de endereços recomendadas (desculpe a tautologia, isso é importante) para destacar:

/ 48 em geral
/ 64 se atrás dela uma e apenas uma sub-rede
/ 128 se um e apenas um dispositivo

O documento ofensivo RFC 2119, que governa a aplicação de vários níveis de cumprimento obrigatório de instruções, define “recomendado” da seguinte forma:
As palavras “Deveriam” ou “Recomendado” significam que pode haver razões razoáveis em determinadas circunstâncias para não agir dessa maneira, no entanto, a escolha de uma linha de comportamento diferente deve ser uma decisão equilibrada, tomada com total entendimento das consequências.
Talvez ninguém tenha entendido completamente as consequências naquele momento, talvez “certas circunstâncias” não tenham sido definidas, mas, de um jeito ou de outro, todos seguiram as recomendações.

Em geral, no momento da redação do documento, o tráfego IPv6 era extremamente raro e era encontrado, em grande parte, em institutos e redes pessoais de entusiastas curiosos. Alguns problemas reais começaram a se acumular e analisar, mas levou muito tempo.
O repensar começou em 2005. Por fim, essas recomendações foram descontinuadas em 2011.

Consciência do problema: RFC 6177

A nova política de endereçamento afirma explicitamente que / 48 é apenas um desejo, não um requisito. Nenhuma indicação de números específicos é fornecida, no entanto, é indicado que / 64 ou menos funciona em condições normais.

A principal lógica em recomendar o tamanho da emissão do bloco / 48 ao consumidor final buscava três objetivos.

Primeiro, o espaço de endereço atribuído deve ser suficiente para fins do consumidor e facilmente extensível, sem agachamento com barra. Sim, é exatamente o que diz, apenas na versão em inglês - salte pelos bastidores. Um dos motivos importantes para mudar para o IPv6 é alterar o tamanho do destino existente de "endereço único" para "várias sub-redes".

Em segundo lugar, a mudança de provedor deveria ter sido realizada com um mínimo de problemas. Se você pode salvar o antigo esquema de endereço de sub-rede ao mudar para um novo espaço de endereço, isso economizará muito trabalho.Em

terceiro lugar, a alocação do bloco / 48 deve cobrir o aumento nas necessidades do espaço de endereço de um consumidor em desenvolvimento.

Embora todas essas condições tenham sido cumpridas, tornou-se evidente que a recomendação / 48 era, para dizer o mínimo, redundante.

Pin / 64 como unidades de emissão

Além da ordem de distribuição, havia outros pontos. Acontece que muitos recursos do IPv6 não funcionam se o prefixo da rede não for / 64. Ou seja, eles não funcionam:

ND (descoberta de vizinhos)
Descoberta segura de vizinhos (SEND)
algumas partes do IPv6 móvel
Multihoming de sites por intermediação IPv6
muitas coisinhas diferentes

Um fator adicional foi o fato de muitas das tecnologias projetadas dependerem exatamente desse prefixo de rede.

Não apenas a ameaça de quebrar o novo padrão foi a razão para escrever novas recomendações. Duas opiniões de validade duvidosa também foram muito populares.
Primeiro, muitos dispositivos implementam o roteamento IPv6 programaticamente, com muletas e bicicletas e, portanto, não estão prontos para uma transição completa para ele. Um possível aumento no atraso devido a isso pode aumentar muitas vezes, se não uma ordem de magnitude. A definição padrão da sub-rede / 64 reduziria bastante esses atrasos.

Segundo, mudar para um novo padrão é sempre um problema para o suporte técnico e os administradores de sistema. Um único prefixo / 64 deveria reduzir essa dor a um valor aceitável.

A situação nas frentes

Como já aconteceu no início de 2001, a recomendação / 64 é percebida por muitos grandes players da Internet como um padrão. Por um lado, é bom, por outro lado, não é tão bom.

Para muitos sistemas de classificação, por exemplo, para reconhecimento de spam, todos os endereços de um bloco serão considerados pertencentes a um remetente de spam. Em teoria, isso deve facilitar a vida do usuário, de fato, exatamente o oposto.

Freqüentemente, os provedores não se preocupam com coisas como aprender sobre práticas comuns. Os endereços podem ser emitidos de acordo com qualquer princípio, pelo menos mesmo de acordo com o horóscopo.

Existem vários problemas típicos, e todos eles decorrem da violação das recomendações do fornecedor, por um lado, e da estrita adesão a elas por outras organizações, por outro.
A emissão de endereços de um bloco para vários usuários pode levar ao fato de que todos serão considerados como um usuário real, por exemplo, máquinas na rede da organização.

Se várias pessoas deste bloco começarem a procurar gatos ao mesmo tempo, o Google poderá decidir que essa botnet enviará solicitações de fraude de pesquisa ou outras coisas não muito boas. Do ponto de vista dele, esse é apenas um usuário. O resultado lógico é um captcha cada vez mais complicado.

Esta, como você sabe, é a resposta mais inofensiva a uma fraude hipotética.
A situação inversa é a emissão para um usuário de endereços de diferentes blocos. Se os usuários desses blocos caírem na lista negra de alguém, os endereços de um usuário honesto cairão com eles. História particularmente interessante: alguns de seus endereços foram banidos por uma rede de publicidade, alguns foram banidos por outra.

Além disso, outras surpresas desagradáveis são possíveis. Por exemplo, você recebeu o bloco / 64 para uso, mas este é um bloco dinâmico como endereço dinâmico - hoje 2001: DA8: 1D01: FA13 :: / 64, amanhã 2001: DA8: 1D01: FC15 :: / 64. Novas aventuras todos os dias!
Há uma chance considerável de encontrar várias combinações desses problemas e outros ancinhos fantasiosamente curvados no apêndice.

Emitir IPv6 do nosso servidor

Se tivermos quintilhões de endereços IP, por que não dar endereços IP reais, por exemplo, para clientes VPN, para que eles acessem a Internet sem NAT e possam aceitar conexões de entrada do mundo. Parece ótimo, mas na prática não é tão fácil. Isso exigirá uma rede IPv6 separada, roteada através do endereço IP atribuído à interface do servidor.

Suponha que um servidor tenha um endereço atribuído 2a01:baba::c0fee:dead/64, e os clientes VPN precisarão de uma rede separada, 2a01:baba:fafa:0f0f::/64como roteada pelo endereço 2a01:baba::c0fee:dead/64.

Infelizmente, muito poucos provedores de hospedagem têm as ferramentas para emitir essas redes para os clientes, e é por isso que você precisa usar muletas como o ND Proxy .

Conclusão

Ler as recomendações da IETF não é a atividade mais interessante, mas é extremamente útil. Preenchê-los com longas noites de inverno claramente não vale a pena, mas também deixar de ler seções importantes para você também é indesejável.

Ao escolher um provedor, verifique se ele compartilha esse ponto de vista.

Você deve entender que a abordagem incorreta para a alocação de endereços não prejudica o provedor e, para a maioria dos contratos, ela não pode ser a base da compensação.
No entanto, isso pode ser um fator-chave para você, embora você ainda não suspeite.