Resumo
- A RFC 1335 propunha que cada host mantivesse um endereço permanente dentro de sua rede e obtivesse temporariamente um endereço externo globalmente único por meio de um External Address Sharing Service (EASS).
- O documento era informativo e se apresentava como uma “ideia”, não como relato de implantação: as evidências disponíveis não mostram que operadores o tenham implementado nem que ele tenha resolvido o esgotamento do IPv4.
É comum imaginar o endereço de Internet como um rótulo preso a uma máquina. A RFC 1335 perguntou se esse rótulo precisava ser global o tempo todo. Em meio às preocupações do início dos anos 1990 com o espaço de endereços de 32 bits, a proposta separou o endereço útil dentro de uma rede daquele endereço escasso necessário para falar com o mundo externo.
O próprio memorando deixa claro seu status. Datado de maio de 1992, ele se identifica como informativo, afirma não especificar um padrão da Internet, chama a si mesmo de documento de “ideia” e convida à discussão. Isso importa: o texto registra o que uma proposta considerou possível, não que um serviço estivesse em operação. RFC 1335
A pressão vinha do sistema de alocação por classes tal como descrito pelos autores. Uma tabela identificada como abril de 1992 contava 7.006 redes Classe B alocadas de um total de 16.383 e advertia que o espaço B poderia acabar em breve se o crescimento continuasse. A Classe C oferecia muito mais números de rede, mas apenas 254 números de host por rede — pouco para a maioria, na avaliação do memorando. São números e projeções do documento naquela época, não uma medição retrospectiva de quando o esgotamento ocorreu.
A RFC 1335 comparava sua proposta com opções então debatidas. Supernetting e o que o texto chamava de C-sharp reorganizariam as alocações Classe C, mas, segundo o memorando, exigiriam alterações no roteamento externo e talvez coordenação global. Outra família de propostas reutilizaria o campo de 32 bits com outro significado e faria reescrita nas fronteiras, o que, na avaliação dos autores, exigiria mudanças substanciais em gateways e roteamento. Essa é a caracterização feita pelo memorando, não uma avaliação neutra de cada alternativa.
O Dual Network Addressing (DNA) dividia as funções. Cada máquina manteria um endereço interno, único apenas dentro de sua própria rede, como endereço permanente naquele ambiente. A rede também teria um conjunto limitado de endereços externos globalmente únicos. Quando um host precisasse falar com outra rede, poderia solicitar um endereço externo temporário ao External Address Sharing Service local e devolvê-lo depois. O EASS seria um ponto técnico e administrativo de alocação entre o uso interno e o alcance global — não uma afirmação de que um endereço autentica uma pessoa, host ou transação.
A política não era simplesmente “todos compartilham”. A RFC 1335 descrevia três classes: máquinas que precisassem de comunicação externa frequente, tanto de entrada quanto de saída, poderiam receber endereços externos permanentes; máquinas impedidas de se comunicar com o exterior não receberiam nenhum; e as demais poderiam compartilhar endereços temporários para conexões iniciadas pelo cliente, sem aceitar chamadas externas no arranjo descrito. Alocação, portanto, era uma questão de política operacional tanto quanto de formato de pacote.
Para funcionar, a proposta exigiria mudanças no software dos hosts para suportar duas interfaces ou endereços IP lógicos em uma interface física. O memorando também propunha DNS sensível à origem: o servidor de nomes poderia responder com um endereço interno ou externo conforme a origem da consulta. O texto sugere que o DHCP poderia cumprir a função do EASS. Isso é uma sugestão de projeto, não evidência de que o DHCP tenha implantado DNA ou de que os dois sistemas formem uma linhagem direta.
A promessa de adoção gradual por cada rede é o aspecto de governança mais interessante. A RFC 1335 argumentava que redes poderiam adotar DNA em momentos diferentes sem alterar algoritmos de roteamento externo nem afetar aquelas que não o adotassem. A intervenção proposta sairia da coordenação global de roteamento e iria para os conjuntos locais de endereços, o software dos hosts e as políticas da rede. Mas o documento não apresenta registros de implantação, testes de interoperabilidade, observações de tráfego ou contagens de adoção que permitam verificar a promessa.
Documentos posteriores ajudam a marcar limites, não a provar uma sucessão. As RFCs 1518 e 1519 estabeleceram o CIDR como estratégia padronizada de alocação de endereços e agregação de rotas; o CIDR atua na escala de prefixos e roteamento, diferente dos endereços internos e do conjunto temporário do DNA. A RFC 1531 especificou depois o DHCP como uma estrutura de configuração que incluía alocação reutilizável de endereços, mas isso não demonstra que o EASS tenha sido implementado. A RFC 1631 descreveu tradução de endereços em uma fronteira: uma comparação limitada, não prova de que DNA tenha causado o NAT. E a RFC 1752 registra uma recomendação de IPng aceita pela IESG, decisão institucional diferente do documento aberto de ideias da RFC 1335. RFC 1287 · RFC 1518 · RFC 1519 · RFC 1531 · RFC 1631 · RFC 1752
A RFC 1335 oferece aos historiadores uma separação clara entre proposta e resultado. A escassez de endereços poderia ser enfrentada alterando quem recebe um número globalmente único, por quanto tempo e sob qual política local — não apenas ampliando ou reorganizando o sistema global de roteamento. O texto não prova que o arranjo tenha sido implantado, que fosse seguro ou interoperável, ou que tenha funcionado. O próprio memorando afirma que não discute segurança. Um endereço temporário pode ser um mecanismo de alocação; não é identidade, autorização, prova de alcance ou evidência de que uma troca entre aplicações foi concluída.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
