O IPv6 - Soluções

Diante desse cenário, a IETF (Internet Engineering Task Force) passa a discutir estratégias para solucionar a questão do esgotamento dos endereços IP e do aumento da tabela de roteamento. Em função disso, em novembro de 1991, é formado o grupo de trabalho ROAD (ROuting and Addressing), que apresenta como solução a estes problemas, a utilização do CIDR (Classless Inter-domain Routing).

Definido na RFC 4632 (tornou obsoleta a RFC 1519), o CIDR tem como idéia básica o fim do uso de classes de endereços, permitindo a alocação de blocos de tamanho apropriado a real necessidade de cada rede; e a agregação de rotas, reduzindo o tamanho da tabela de roteamento. Com o CIDR os blocos são referenciados como prefixo de redes. Por exemplo, no endereço a.b.c.d/x, os x bits mais significativos indicam o prefixo da rede. Outra forma de indicar o prefixo é através de máscaras, onde a máscara 255.0.0.0 indica um prefixo /8, 255.255.0.0 indica um /16, e assim sucessivamente.

Outra solução, apresentada na RFC 2131 (tornou obsoleta a RFC 1541), foi o protocolo DHCP (Dynamic Host Configuration Protocol). Através do DHCP um host é capaz de obter um endereço IP automaticamente e adquirir informações adicionais como máscara de sub-rede, endereço do roteador padrão e o endereço do servidor DNS local.

O DHCP tem sido muito utilizado por parte dos ISPs por permitir a atribuição de endereços IP temporários a seus clientes conectados. Desta forma, torna-se desnecessário obter um endereço para cada cliente, devendo-se apenas designar endereços dinamicamente, através de seu servidor DHCP. Este servidor terá uma lista de endereços IP disponíveis, e toda vez que um novo cliente se conectar à rede, lhe será designado um desses endereço de forma arbitrária, e no momento que o cliente se desconecta, o endereço é devolvido.

A NAT (Network Address Translation), foi outra técnica paliativa desenvolvida para resolver o problema do esgotamento dos endereços IPv4. Definida na RFC 3022 (tornou obsoleta a RFC 1631), tem como ideia básica permitir que, com um único endereço IP, ou um pequeno número deles, vários hosts possam trafegar na Internet. Dentro de uma rede, cada computador recebe um endereço IP privado único, que é utilizado para o roteamento do tráfego interno. No entanto, quando um pacote precisa ser roteado para fora da rede, uma tradução de endereço é realizada, convertendo endereços IP privados em endereços IP públicos globalmente únicos.

Para tornar possível este esquema, utiliza-se os três intervalos de endereços IP declarados como privados na RFC 1918, sendo que a única regra de utilização, é que nenhum pacote contendo estes endereços pode trafegar na Internet pública. As três faixas reservadas são:‏

• 10.0.0.0 a 10.255.255.255 /8 (16.777.216 hosts)
• 172.16.0.0 a 172.31.255.255 /12 (1.048.576 hosts)
• 192.168.0.0 a 192.168.255.255 /16 (65.536 hosts)

A utilização da NAT mostrou-se eficiente no que diz respeito a economia de endereços IP, além de apresentar alguns outros aspectos positivos, como facilitar a numeração interna das redes, ocultar a topologia das redes e só permitir a entrada de pacotes gerados em resposta a um pedido da rede. No entanto, o uso da NAT apresenta inconvenientes que não compensam as vantagens oferecidas.

A NAT quebra o modelo fim-a-fim da Internet, não permitindo conexões diretas entre dois hosts, o que dificulta o funcionamento de uma série de aplicações, como P2P, VoIP e VPNs. Outro problema é a baixa escalabilidade, pois o número de conexões simultâneas é limitado, além de exigir um grande poder de processamento do dispositivo tradutor. O uso da NAT também impossibilita rastrear o caminho de pacote, através de ferramentas como traceroute, por exemplo, e dificulta a utilização de algumas técnicas de segurança como IPSec. Além disso, seu uso passa uma falsa sensação de segurança, pois, apesar de não permitir a entrada de pacotes não autorizados, a NAT não realiza nenhum tipo de filtragem ou verificação nos pacotes que passa por ela.

A imagem abaixo mostra o quanto essas medidas ajudaram a diminuir o aumento da alocação de endereço:

Embora estas soluções tenham diminuído a demanda por IPs, elas não foram suficientes para resolver os problemas decorrentes do crescimento da Internet. A adoção dessas técnicas reduziu em apenas 14% a quantidade de blocos de endereços solicitados à IANA e a curva de crescimento da Internet continuava apresentando um aumento exponencial.

Essas medidas, na verdade, serviram para que houvesse mais tempo para se desenvolver uma nova versão do IP, que fosse baseada nos princípios que fizeram o sucesso do IPv4, porém, que fosse capaz de suprir as falhas apresentadas por ele.

Deste modo, em dezembro de 1993 a IETF formalizou, através da RFC 1550, as pesquisas a respeito da nova versão do protocolo IP, solicitando o envio de projetos e propostas para o novo protocolo. Esta foi umas das primeiras ações do grupo de trabalho da IETF denominado Internet Protocol next generation (IPng). As principais questões que deveriam ser abordadas na elaboração da próxima versão do protocolo IP foram:

• Escalabilidade;
• Segurança;
• Configuração e administração de rede;
• Suporte a QoS;
• Mobilidade;
• Políticas de roteamento;
• Transição.

Soluções em protocolos

Diversos projetos começaram a estudar os efeitos do crescimento da Internet, sendo os principais o CNAT, o IP Encaps, o Nimrod e o Simple CLNP. Destas propostas surgiram o TCP and UDP with Bigger Addresses (TUBA), que foi uma evolução do Simple CLNP, e o IP Address Encapsulation (IPAE), uma evolução do IP Encaps. Alguns meses depois foram apresentados os projetos Paul’s Internet Protocol (PIP), o Simple Internet Protocol (SIP) e o TP/IX. Uma nova versão do SIP, que englobava algumas funcionalidades do IPAE, foi apresentada pouco antes de agregar-se ao PIP, resultando no Simple Internet Protocol Plus (SIPP). No mesmo período, o TP/IX mudou seu nome para Common Architecture for the Internet (CATNIP).

Em janeiro de 1995, na RFC 1752 o IPng apresentou um resumo das avaliações das três principais propostas:

• CANTIP – foi concebido como um protocolo de convergência, para permitir a qualquer protocolo da camada de transporte ser executado sobre qualquer protocolo de camada de rede, criando um ambiente comum entre os protocolos da Internet, OSI e Novell;
• TUBA – sua proposta era de aumentar o espaço para endereçamento do IPv4 e torná-lo mais hierárquico, buscando evitar a necessidade de se alterar os protocolos da camada de transporte e aplicação. Pretendia uma migração simples e em longo prazo, baseada na atualização dos host e servidores DNS, entretanto, sem a necessidade de encapsulamento ou tradução de pacotes, ou mapeamento de endereços;
• SIPP – concebido para ser uma etapa evolutiva do IPv4, sem mudanças radicais e mantendo a interoperabilidade com a versão 4 do protocolo IP, fornecia uma plataforma para novas funcionalidades da Internet, aumentava o espaço para endereçamento de 32 bits para 64 bits, apresentava um nível maior de hierarquia e era composto por um mecanismo que permitia “alargar o endereço” chamado cluster addresses. Já possuía cabeçalhos de extensão e um campo flow para identificar o tipo de fluxo de cada pacote.

Entretanto, conforme relatado também na RFC 1752, todas as três propostas apresentavam problemas significativos. Deste modo, a recomendação final para o novo Protocolo Internet baseou-se em uma versão revisada do SIPP, que passou a incorporar endereços de 128 bits, juntamente com os elementos de transição e autoconfiguração do TUBA, o endereçamento baseado no CIDR e os cabeçalhos de extensão. O CATNIP, por ser considerado muito incompleto, foi descartado.

Após esta definição, a nova versão do Protocolo Internet passou a ser chamado oficialmente de IPv6.

Veja outra postagem relacionada com o assunto:

O IPV6 - Introdução

Até a próxima postagem! ;)

Fonte: http://ipv6.br