• A Internet e o TCP/IP
• Esgotamento dos endereços IPv4
• Soluções

Este módulo de introdução, apresenta um pouco da história da Internet. Também são analisadas informações sobre o desenvolvimento do protocolo IP para entender quais os problemas causados pela forma de distribuição dos endereços IP adotada inicialmente e pelo rápido crescimento da Internet. É apresentado na sequência informações sobre as soluções aplicadas para resolver esses problemas. Seguindo este histórico, veremos como algumas dessas soluções evoluíram até se chegar a definição da versão 6 do protocolo de internet, o IPv6.

A Internet e o TCP/IP

O Departamento de Defesa (DoD – Department of Defense) do governo estadunidense iniciou em 1966, através de sua Agencia de Pesquisas e de Projetos Avançados (ARPA – Advanced Research Projects Agency), um projeto para a interligação de computadores em centros militares e de pesquisa. Este sistema de comunicação e controle distribuído com fins militares recebeu o nome de ARPANET, tendo como principal objetivo teórico formar uma arquitetura de rede sólida e robusta que pudesse, mesmo com a queda de alguma estação, trabalhar com os computadores e ligações de comunicação restantes. Em 1969, são instalados os primeiros quatro nós dessa rede, localizados na Universidade de Los Angeles (UCLA), na Universidade da Califórnia em Santa Bárbara (UCSB), no Instituto de Pesquisas de Standford (SRI) e na Universidade de Utah.

No início, a ARPANET trabalhava com diversos protocolos de comunicação, com enfoque no NCP (Network Control Protocol). No entanto, no primeiro dia de janeiro de 1983, quando a rede atingiu a marca de 562 hosts, todas as máquinas da ARPANET passaram a adotar como padrão os protocolos TCP/IP. Essa mudança então, ocasionou o crescimento ordenado da rede a partir da eliminação das restrições feitas pelos protocolos anteriores.

O protocolo IP foi definido na RFC 791 para prover duas funções básicas: a fragmentação, que permite o envio de pacotes maiores que o limite de tráfego estabelecido num enlace, dividindo-os em partes menores; e o endereçamento, que permite identificar o destino e a origem dos pacotes a partir dos endereços armazenados no cabeçalho do protocolo. Sua versão de protocolo, utilizada desde aquela época até os dias atuais, é a 4, comummente referenciada com o nome do protocolo de IPv4. Apesar dessa versão se mostrar muito robusta, e de fácil implantação e interoperabilidade, seu projeto original não previu alguns aspectos como:

• O crescimento das redes e um possível esgotamento dos endereços IP;
• O aumento da tabela de roteamento;
• Problemas relacionados a segurança dos dados transmitidos;
• Prioridade na entrega de determinados tipos de pacotes.

Esgotamento dos endereços IPv4

As especificações do IPv4 reservam 32 bits para endereçamento, o que possibilita gerar mais de 4 bilhões de endereços distintos. Inicialmente, estes endereços foram divididos em três classes de tamanhos fixos da seguinte forma:

• Classe A: definia o bit mais significativo como 0, utilizava os 7 bits restantes do primeiro octeto para identificar a rede, e os 24 bits restantes para identificar o host. Esses endereços utilizavam a faixa de 1.0.0.0 até 126.0.0.0;
• Classe B: definia os 2 bits mais significativo como 10, utilizava os 14 bits seguintes para identificar a rede, e os 16 bits restantes para identificar o host. Esses endereços utilizavam a faixa de 128.1.0.0 até 191.254.0.0;
• Classe C: definia os 3 bits mais significativo como 110, utilizava os 21 bits seguintes para identificar a rede, e os 8 bits restantes para identificar o host. Esses endereços utilizavam a faixa de 192.0.1.0 até 223.255.254.0;

Classe	Formato	Redes	Hosts
A	7 bits Rede, 24 bits Host	128	16.77.216
B	14 bits Rede, 16 bits Host	16.384	66.536
C	21 bits Rede, 8 bits Host	2.097.152	256

Embora o intuito dessa divisão tenha sido tornar a distribuição de endereços mais flexível, abrangendo redes de tamanhos variados, esse tipo de classificação mostrou-se ineficiente. A classe A atendia um número muito pequeno de redes e ocupava metade de todos os endereços disponíveis, enquanto que a classe C permitia criar muitas redes só que com poucos endereços disponíveis. Em outras palavras, ao mesmo tempo em que algumas classes acarretavam desperdícios, as outras não supriam a necessidade de endereços disponíveis. Para exemplificar o problema, imagine que precise-se endereçar 300 dispositivos em uma rede. Nessa situação seria necessário obter um bloco de endereços da classe B, desperdiçando assim quase o total dos 65 mil endereços.

Outro fator que colaborava com o desperdício de endereços, foi a politica de distribuição de faixas classe A, as quais foram atribuídas integralmente a grandes instituições como IBM, AT&T, Xerox, HP, Apple, MIT, Ford, Departamento de Defesa Americano, entre muitas outras.Isso disponibilizava para cada uma 16.777.216 milhões de endereços que dificilmente seriam usadas por completo. Para complicar a situação, 35 faixas de endereços classe A foram reservadas para usos específicos como multicast, loopback e uso futuro.

Em 1990, já existiam 313.000 hosts conectados a rede e estudos já apontavam para um colapso devido a falta de endereços. Além disso outros problemas também tornavam-se mais efetivos conforme a Internet evoluía, como o aumento da tabela de roteamento.

Devido ao ritmo de crescimento da Internet e da política de distribuição de endereços, em maio de 1992, 38% das faixas de endereços classe A, 43% da classe B e 2% da classe C, já estavam alocados. Nesta época, a rede já possuía 1.136.000 hosts conectados.

Em 1993, com a criação do protocolo HTTP e a liberação por parte do Governo estadunidense para a utilização comercial da Internet, houve um salto ainda maior na taxa de crescimento da rede, que passou de 2.056.000 de hosts em 1993 para mais de 26.000.000 de hosts em 1997.

Distribuição dos endereços em 2008

Esta imagem mostra uma visualização das informações da tabela de roteamento BGP extraída do projeto Routeviews. Nela, o espaço de endereço IPv4 unidimensional é mapeado em uma imagem de bidimensional, onde blocos CIDR sempre aparecem como quadrados ou retângulos.

Mais informações

RFC 1287 – Towards the Future Internet Architecture.
RFC 1296 – Internet Growth (1981-1991)‏
Solensky F., ‘Continued Internet Growth’, Proceedings of the 18th Internet Engineering Task Force, Agosto 1990, http://www.ietf.org/proceedings/prior29/IETF18.pdf
IANA IPv4 Address Space Registry – http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
RFC 3330 – Special-Use IPv4 Addresses.

http://maps.measurement-factory.com/

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.

Mais informações

RFC 1380 – IESG Deliberations on Routing and Addressing
RFC 1918 – Address Allocation for Private Internets
RFC 2131 – Dynamic Host Configuration Protocol
RFC 2775 – Internet Transparency
RFC 2993 – Architectural Implications of NAT
RFC 3022 – Traditional IP Network Address Translator (Traditional NAT)
RFC 3027 – Protocol Complications with the IP Network Address Translator
RFC 4632 – Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.
RFC 1550 – IP: Next Generation (IPng) White Paper Solicitation
RFC 1752 – The Recommendation for the IP Next Generation Protocol