Resumo

  • RFC 1918 reservou 10/8, 172.16/12 e 192.168/16 para uso repetido sem coordenação global. A promessa de unicidade vale dentro de uma empresa ou de um conjunto que coordena o espaço.
  • Uma fusão não prova que uma das redes estava errada. Ela amplia o domínio de comunicação e faz duas atribuições locais, antes inequívocas, disputarem o mesmo significado.
  • Rota, DNS, tradução, credencial e resultado da aplicação formam evidências separadas. A conectividade pode funcionar e ainda assim entregar tráfego ao host errado.

A conexão que parecia pronta

Considere duas organizações que usam 10.12.0.15. Em uma, o endereço chega a um resolvedor interno; na outra, a um servidor de gestão. Cada uma mantém sua própria tabela, seu DHCP, seus nomes e suas regras de acesso. Durante anos, não há conflito porque nenhum pacote precisa escolher entre os dois significados.

A interconexão elimina essa garantia ambiental. Para o roteador combinado, o prefixo se tornou ambíguo. O endereço não leva o nome da empresa nos 32 bits. A separação administrativa funcionava como uma coordenada implícita. Quando ela some, uma rota simples não tem como recuperar a intenção do emissor.

É por isso que RFC 1918 deve ser lido como uma decisão sobre escopo, não apenas como uma lista de faixas. A comunidade reduziu a necessidade de coordenação antes da instalação e aceitou uma obrigação futura: caso os domínios viessem a se encontrar, alguém teria de separar, mapear ou alterar números.

A objeção chegou dois anos antes do BCP

RFC 1597 apresentou em março de 1994 o modelo de endereçamento para internets privadas. A motivação era concreta. Muitos hosts usavam TCP/IP apenas dentro de uma empresa: terminais, caixas, painéis e interfaces internas não precisavam de conectividade direta com qualquer máquina da Internet. Reservar espaço reutilizável economizava números globalmente únicos e dava liberdade ao projeto local.

Em julho, RFC 1627 respondeu que o isolamento de hoje não assegura o isolamento de amanhã. Empresas colaboram e se fundem; máquinas ganham novas funções; serviços, licenças e configurações podem depender de um endereço. O texto menciona uma renumeração de milhares de hosts na Apple. Este pacote não possui comprovação independente da contagem, do custo ou do desfecho, portanto o exemplo registra o argumento contemporâneo, não uma medição universal.

RFC 1918, publicado em fevereiro de 1996 como BCP 5, tornou obsoletos os dois textos. Eliot Lear, autor da crítica, também assinou o novo documento. O compromisso final não apagou o risco levantado em 1994. A seção de desvantagens diz que internets privadas antes não coordenadas podem, ao se fundir, conter endereços não únicos e exigir renumeração.

Esse detalhe muda a narrativa. O choque futuro não foi uma falha secreta encontrada depois. Foi um custo conhecido que a prática decidiu assumir em troca de benefícios imediatos.

A regra cabe dentro do perímetro

Os três blocos de RFC 1918 são 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16. Uma empresa pode utilizá-los sem procurar IANA ou um registro de Internet; muitas empresas podem repetir a escolha. A unicidade existe somente dentro da empresa ou do grupo de empresas que resolveu cooperar sobre o mesmo plano.

O registro atual de endereços especiais da IANA ainda classifica as faixas como Private-Use e não Globally Reachable. Esse registro não decide qual empresa tem o uso “verdadeiro” de um /24 privado. Não há prioridade mundial a registrar, pois a reutilização é a finalidade.

Outras superfícies precisam preservar o mesmo escopo. RFC 1918 determina que rotas privadas não sejam propagadas em enlaces entre empresas, que pacotes com origem ou destino privado não atravessem tais limites e que referências indiretas, inclusive registros DNS, permaneçam internas. Se o nome é publicado para um público maior que o endereço pode distinguir, o vazamento de contexto começa antes do primeiro erro de rota.

O documento também não prometeu segurança. Sua seção correspondente declara que o tema não é tratado. Filtragem e gateways podem acompanhar uma rede privada, mas um endereço não roteável globalmente não autentica pessoa, máquina nem aplicação.

Ninguém é dono do número repetível

Além do cenário de fusão, RFC 1918 alerta para organizações que decidem estabelecer conectividade IP posteriormente. Ele recomenda selecionar sub-blocos privados de forma aleatória para reduzir o risco de coincidência. Reduzir não significa eliminar, e sorteio não cria um direito de precedência.

Uma integração responsável não pergunta quem chegou primeiro ao 10/8. Pergunta qual rede pode mudar com evidência, qual serviço carrega identidade de negócio, quais equipes possuem a configuração, que dependências externas existem, qual interrupção é aceitável e se a tradução será ponte ou arquitetura permanente.

O próprio RFC lembra que mover um host entre condição privada e pública altera endereço, DNS e arquivos de configuração em outras máquinas. DHCP pode ajudar na mecânica. Não decide quem absorve o custo, não localiza toda referência e não verifica se o serviço certo voltou.

O ganho inicial e a despesa posterior pertencem a momentos e pessoas diferentes. A liberdade local é real; a dívida de integração também.

Address realm: o sobrenome que faltava

RFC 2663 trouxe em 1999 a expressão address realm: o domínio no qual endereços são atribuídos de maneira única e o roteamento consegue localizar as entidades. A definição explicita o sobrenome do número. 10.12.0.15 no realm A e no realm B são identificadores úteis porque cada um vem acompanhado, ainda que silenciosamente, do seu contexto.

A NAT tradicional cria uma correspondência entre um realm privado e um externo, mas pressupõe que os espaços não se sobreponham. Quando o mesmo valor já tem uso dos dois lados, RFC 2663 descreve twice NAT, capaz de modificar origem e destino. Ela oferece a cada domínio uma representação roteável do outro; não transforma o endereço privado original em identidade global.

RFC 3022 detalha Basic NAT e NAPT. A primeira mapeia endereços; a segunda inclui identificadores de transporte. Solicitações e respostas devem atravessar estado de tradução coerente. Um desvio para outro equipamento sem esse estado pode derrubar o fluxo. O mecanismo poupa alterações imediatas nos hosts, mas reduz o significado fim a fim do IP e adiciona memória ao caminho.

Por isso, a tabela de tradução é parte da prova operacional. Um log útil precisa conservar realm de origem, instante, protocolo, representação interna, representação externa e dispositivo que tomou a decisão. Sem esses campos, um número correto pode descrever vários eventos.

O host errado também responde

RFC 5684, uma Independent Submission de 2010 e não uma especificação do IETF Standards Track, examinou sobreposição em NATs encadeadas e VPNs de acesso remoto. Em um exemplo, o endereço divulgado para um resolvedor da rede acima coincide com o de um host local; a consulta permanece na rede local. Em outro, o serviço do local remoto pode ser confundido com o serviço corporativo que o usuário pretendia acessar.

O documento chama o problema de mistaken end host identity. Ele é mais traiçoeiro que a falta de rota, porque pode haver resposta. Para os cenários descritos, recomenda endereços não sobrepostos ou globais em certos serviços críticos e autenticação fim a fim, em vez de depender apenas do IP de origem.

Não há ali uma taxa de ocorrência para fusões, e a publicação não prova que todo overlap gera sequestro. O limite factual é suficiente: alcance e identidade podem divergir. Configuração prova um número no âmbito local; rota prova uma decisão de encaminhamento; mapa prova uma conversão; credencial prova um par; a aplicação prova um resultado. Um único indicador verde não substitui o conjunto.

Espaço compartilhado tem outro administrador

RFC 6598 criou em 2012 100.64.0.0/10 para Shared Address Space entre CGN de provedores e equipamentos de clientes. O texto o distingue do espaço privado empresarial de RFC 1918. A IANA registra ambos como especiais e não globalmente alcançáveis, porém o perímetro previsto não é o mesmo.

Isso evita tratar casa, empresa e rede do provedor como um único “lado de dentro”. Cada realm tem responsáveis, rotas, nomes e riscos de sobreposição próprios. A mesma aparência numérica não transfere a regra de um domínio ao outro.

RFC 1918 não aboliu a unicidade. Ele permitiu mantê-la perto de quem precisava dela. Enquanto as fronteiras ficaram estáveis, a economia funcionou de maneira quase invisível. Quando duas redes se encontram, a fronteira deixa de fazer trabalho gratuito. A integração deve então dar ao endereço um contexto explícito, criar um mapa auditável ou mudar o número — e comprovar separadamente que o serviço e o interlocutor corretos sobreviveram.

Fontes