Uma rede apenas com IPv6: a forma mais simples e segura de operar uma rede
16/10/2023
Silvia Hagen * – Proprietária, Consultora Sênior e Coach Sistêmica de Sunny Connection AG
Meu interesse pelo IPv6 remonta a 1997. Nesse momento estava escrevendo meu primeiro livro técnico, “Resolução de problemas em TCP/IP”. Ao chegar no último capítulo, senti o impulso de sair e ver como poderia ser o futuro. E foi assim que encontrei o primeiro livro de Christian Huitema, “IPv6: o novo protocolo da Internet”. Tratava-se de um livro pequeno – de umas 100 páginas – e no último capítulo do meu livro eu o resumi em dois ou três parágrafos, dizendo: “há um novo protocolo no horizonte, um que eventualmente ajudará a resolver o problema dos endereços IPv4”. Creio que naquele momento era o único livro disponível sobre IPv6. Não consigo explicar porquê, mas por alguma razão este assunto me fascinou.
Foi assim que quando O’Reilly me chamou, três anos mais tardes, e me perguntou se eu podia escrever um livro sobre o IPv6, não hesitei em dizer que sim. Já sabia, por experiência própria, após ter escrito o primeiro livro sobre TCP/IP, que não há melhor maneira de aprender algo que escrevendo um livro sobre o assunto. E eu estava convencida de que o IPv6 seria o futuro Protocolo da Internet, razão pela qual, valia a pena aprofundar sobre ele. Naqueles primeiros anos, poucos tinham ouvido falar do IPv6, portanto foram principalmente os desenvolvedores que me apoiaram no processo de minha escritura. Desta forma, fui aprendendo da própria fonte.
Desafios no caminho. O desenho do IPv6 começou a princípios da década de 1990. Publicada em 1995, a RFC 1752 foi a primeira RFC sobre o IPv6. Nesse momento chamava-se IPng (next generation). Já naqueles primeiros dias da Internet, os desenvolvedores previram que o espaço de endereços IPv4 se esgotaria em algum momento. Estimaram que isso aconteceria entre 2012 e 2015 (visto de forma retrospectiva, foi uma boa previsão!), então perceberam que tinham tempo suficiente não apenas para ampliar o espaço de endereços, mas também para tentar fazer com que o protocolo fosse mais escalável para grandes estruturas.
Quanto aos desafios para o desenvolvimento e a implementação do IPv6, creio que a NAT (Network Address Translation) tornou-se cada vez mais popular para resolver os problemas derivados da limitação dos endereços, antes de que o IPv6 estivesse suficientemente amadurecido para ser implementado. O IPv6 foi publicado em 1998 com a RFC 2460, um rascunho de RFC, e só depois de um tempo os provedores fizeram suas primeiras implementações. De maneira que, quando o IPv6 ficou pronto para ser usado, muitos já tinham implementado NAT para “resolver” os problemas urgentes que implicava a limitação de endereços e não encontravam motivos para implementar IPv6.
Numa perspectiva a curto prazo, isso é compreensível. Porém, não é compatível com uma perspectiva a longo prazo, nem do ponto de vista da arquitetura da rede nem da perspectiva de um caso de negócio. Pensando a longo prazo, NAT, deveria revezar-se por uma solução que foi criada para resolver o problema dos endereços, o IPV6.
Se observarmos isso através da lente da Internet, as empresas deveriam entender que todos somos participantes e co-criadores da Internet. O fato de oferecerem ou não seus serviços de Internet, por exemplo websites e lojas online, através do IPv6, tem um grande impacto em outros ISP e nos usuários finais. Para todos os serviços que são oferecidos via Internet, a orientação é que sejam oferecidos em forma dual-stack ou pilha dupla, isso significa que são acessíveis tanto através do IPv4 como do IPv6. Desta forma, cada usuário final poderá acessar o site mediante o protocolo com o qual tiver melhor rendimento.
Para um ISP, os custos operativos são substancialmente menores se houver uma rota IPv6. É muito mais simples manter e baixar o tráfego de sua rota IPv4 (que costuma ser uma estrutura NAT complexa que gera um alto custo de manutenção). Por tanto, cada website público que oferece seus serviços através do IPv6 baixa tráfego da rota IPv4 e transporta-o mediante a rota IPv6 mais eficiente para todos os ISP na rota. Conforme ele estiver conectado à Internet, para o usuário final, isto pode supor uma grande vantagem quanto ao seu desempenho: se um ISP possuir uma estrutura NAT complexa e talvez sobrecarregada para o IPv4, através do IPv6 poderá acessar qualquer serviço de Internet dual-stack.
Swisscom, um ISP suíço que oferece Internet dual-stack a seus usuários de DSL desde 2012, avaliou seus custos operativos depois de cinco anos. Os resultados foram interessantes.
Custo para uma taxa de transferência efetiva de 1 Gb/s:
6rd: CHF 1’650.00
IPv4 CG-NAT: CHF 8’000.00 (sem custo de registro)
Isso significa que, para Swisscom, entregar dados mediante o IPv4 é quatro vezes mais caro do que fazê-lo através do IPv6. Mais de 35% do tráfego de seu backbone é IPv6 (cifras de 2017). A rota IPv6 reduziu a carga da rota IPv4 em 9 Gb/s.
Portando, seria uma melhora importante que os websites públicos oferecessem seus serviços de forma dual-stack (o que na verdade é algo óbvio do ponto de vista técnico) e que as empresas dessem acesso dual-stack à Internet. Isso aumentaria o tráfego IPv6 em Internet e reduziria o tráfego IPv4.
IPv6: dificuldades nas organizações. O problema principal que eu percebo hoje em dia é que é muito comum – especialmente nas grandes organizações – tomar decisões com uma perspectiva a curto prazo. Se algo não gera benefícios em poucos meses, muitas vezes é excluído do orçamento. E o dinheiro costuma ser uma boa desculpa para não ter que fazer coisas com as quais não queremos lidar. Em muitas conversas com os clientes, percebi que eles acham que o IPv6 é muito complexo e que não conseguirão dominá-lo.Pode parecer extenuante, eu concordo, mas só se não dedicarmos tempo para observar mais de perto. Se observarmos mais de perto, veremos muitos exemplos de empresas que predicaram com o exemplo e comprovaram que é mais fácil e mais barato do que imaginavam. Por outro lado, é difícil gerir um projeto de IPv6 sem apoio a nível de diretoria, uma vez que é necessário ter prioridades e objetivos compartilhados entre diferentes departamentos.
Outro fator que está atrasando a implementação do IPv6 é que o IPv6 é visto como um projeto independente. Assim, a cada ano é analisado como parte de um orçamento anual e a decisão tomada é que não há tempo e que precisam do dinheiro para outros projetos que parecem mais importantes. O fato é que o IPv6 não é um projeto independente, ele deve ser visto como uma parte integral de qualquer projeto. Porque todos os projetos de TI são executados na mesma rede da qual o IPv6 é uma parte integral, como é o caso da segurança. Ninguém diria “não temos tempo nem dinheiro para a segurança. Agora temos de implementar nosso novo centro de dados, da segurança vamos dar conta depois”. Isso não faz sentido, verdade? A mesma coisa acontece com o IPv6!
E quando considerarmos que o IPv6 é uma parte integral de qualquer projeto que a rede utilizar, já não se tratará de algo macro, super complexo e alucinante, mas sim algo que poderá ser visto passo a passo, por projeto. Obviamente, há alguns aspectos que devem ser abordados em todos os projetos, como a arquitetura geral, o plano de endereços e o conceito de segurança. Isto deve ser feito no início para que possa servir de marco para cada projeto individual.
As organizações não são conscientes dos custos ocultos do funcionamento de suas redes IPv4. Uma grande organização com a qual eu trabalhei há pouco tempo analisou este assunto com mais cuidado. Um de seus custos foi por terem comprado endereços IPv4. O preço de mercado de um endereço IPv4 aumentou bastante nos últimos anos.
Em 2013, quando a Microsoft comprou os endereços IPv4 de Nortel, pagou em torno de 12 dólares por cada endereço. Hoje em dia, o custo de um endereço IPv4 aumentou entre 50 e 60 dólares (https://www.ipxo.com/blog/ipv4-price-history). Este cliente pagou por volta de um milhão de dólares por um /16 de endereços IPv4. Se tivessem incluído o IPv6 em seu planejamento com suficiente antecedência, poderiam ter economizado estes custos ou teriam investido este dinheiro na implementação do IPv6.
Este cliente também descobriu que uma grande parte de seus tempos de inatividade e custos de resolução de problemas eram gerados pelas complexas estruturas e dispositivos NAT. Portanto, ao avaliar o custo de implementação do IPv6, estes custos devem ser considerados como economias.
Outro caso no qual foram gerados custos e problemas desnecessários, por não terem implementado o IPv6, foi o da empresa ferroviária suíça SBB. Em 2014 tinham começado a trabalhar no assunto ao criarem um plano de endereços, porém, ao invés de começar uma implementação passo a passo, o plano de endereços foi para parar em uma gaveta, onde permaneceu esquecido. Alguns anos depois, a equipe de negócios decidiu lançar um novo serviço. A data de lançamento seria em um ano. Queriam criar um aplicativo para telefones inteligentes com o intuito de que seus clientes, nos trens, pudessem obter informação sobre seus assentos, espaços de armazenagem e qualquer outra informação relacionada com sua viagem. A equipe de negócios entrou em contato com a equipe responsável pela rede e lhe pediu 1000 endereços por trem para 1200 trens. Esta demanda inesperada não poderia ter sido satisfeita com o IPv4.
De forma que foi preciso que lhe designassem aos dispositivos do trem apenas IPv6. Em razão de que sua infraestrutura de backend continuava sendo só IPv4, tiveram que fazer uma tradução para escrever os dados em seu backend. Se tivessem começado a migrar o backend passo a passo depois de 2014, provavelmente desse para acessar o backend mediante IPv6. Além disso, como o provedor Swiss Mobile só tinha conexão móvel IPv4, os dados tiveram que ser canalizados através dela. Estamos falando do ano 2018. Se todos os participantes da Internet fizessem suas tarefas, estes cenários poderiam ser muito mais simples.
Dado que o IPv4 gera custos muito mais altos de operação, manutenção e resolução de problemas, os provedores e os ISP estão gradativamente começando a receber mais pelos serviços IPv4 que pelos serviços IPv6.
Azure, por exemplo, anunciou que começaria a cobrar mais pelos endereços e prefixos IPv4 em julho de 2022. Um endereço IPv4 estático agora custa para a Microsoft $31,50 ao ano, enquanto que os endereços IPv6 estáticos são gratuitos. (https://azure.microsoft.com/en-us/updates/azure-public-ipv6-offerings-are-free-as-of-july-31/)
A mensagem depois de 20 anos. O IPv6 especificou-sena RFC 8200, datada de julho de 2017. É o protocolo de Internet atual e está em constante otimização e desenvolvimento.
O IPv4 se especificou na RFC 791, que data de 1981 e não está mais em desenvolvimento. Chegou ao final de sua vida útil em 2011, quando a IANA entregou os últimos cinco bloques de endereços IPv4.
Os responsáveis pelo desenvolvimento e manutenção de uma rede IPV4 devem levar isso em consideração. É um aspecto importante de proteção dos investimentos. O IPv4 gera muitos custos desnecessários e em algum momento será preciso migrar para o IPv6. Isto significa que qualquer coisa que for instalada sobre o IPv4 terá que ser modificada. Tudo o que possamos implementar sobre o IPv6 é um investimento duradouro. Não é de bom senso investir no protocolo de Internet atual em vez de resolver problemas, consertar, ampliar e criar soluções alternativas para um protocolo obsoleto?
O objetivo deveria ser criar uma rede apenas com o IPv6 o mais rápido possível, uma vez que esta é a forma mais singela e segura de operar uma rede. A partir do dia 29 de junho de 2021, o Departamento de Defesa dos Estados Unidos começou sua transição obrigatória para o IPv6, exigindo que todos os sistemas na rede mudassem para a versão mais atualizada do Protocolo de Internet (IP), o Protocolo de Internet versão 6 (IPv6), antes de findar o ano fiscal de 2025.
No outro extremo do mundo, a China tem estratégias similares. Seu objetivo é que todos os níveis da indústria e do governo implementem redes IPv6 de pilha única para 2030.
(https://www.theregister.com/2021/07/26/china_single_stack_ipv6_notice/)
É um bom conselho! Todos os que fazem parte da Internet deveriam almejar subir nesse trem.
*A autora publicou nove livros sobre o IPv6, considerando as edições e traduções para o alemão.
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.