Resumo

  • A RFC 3102 permitia que um host de um realm privado usasse um endereço público inteiro ou um endereço compartilhado com portas, sob um bind e um lease mantidos pelo gateway.
  • Tornar o parâmetro público visível não resolvia o caminho: o host precisava escolher entre destino local e túnel público, e aplicações multiparte entre realms não tinham solução geral.

O endereço público entrou na pilha do host

No NAT tradicional, o host emitia com endereço privado e o equipamento de borda reescrevia endereço ou porta. A aparente transparência poupava mudanças no host, mas falhava quando protocolos transportavam endereços em seu conteúdo ou dependiam de cabeçalhos intactos.

As RFCs 3102 a 3105, publicadas em outubro de 2001, distribuíram o trabalho de outro modo. O host RSIP primeiro negociava recursos com um gateway entre dois realms de endereçamento. Instalava os parâmetros concedidos em sua pilha, criava o pacote interno com a fonte pública e o levava por um túnel até a borda. O gateway retirava o encapsulamento e encaminhava sem reescrever aquela fonte.

RSA-IP concedia um endereço público exclusivo ao host durante o prazo. RSAP-IP permitia dividir um endereço entre vários hosts, atribuindo a cada um portas não sobrepostas. Um modo emprestava a casa inteira; o outro, entradas específicas no mesmo número.

Em ambos, visibilidade não era propriedade. O host tinha uma presença pública temporária, mas o gateway conservava o pool, decidia o que conceder e podia recusar ou recuperar recursos. A intermediação deixava de ser invisível; não deixava de existir.

O empréstimo tinha identidade, vínculo e relógio

A RFC 3103 descreveu uma máquina de estados. O host registrava-se e recebia um client ID. A resposta de atribuição podia incluir endereço, portas, bind ID, duração, tipo de túnel e política de fluxo. Havia mensagens para estender, consultar, ouvir conexões de entrada, liberar e cancelar o registro.

Cada peça respondia a uma pergunta diferente. Registro dizia que o gateway reconhecia o cliente. Atribuição dizia quais recursos estavam autorizados. O bind ligava a identidade local aos parâmetros públicos. O lease dizia por quanto tempo. A política limitava os destinos ou portas remotos. Nenhuma dessas respostas, isoladamente, mostrava que a rota fora instalada, o túnel estava ativo ou um pacote retornara.

O host podia sugerir um endereço ou porta, mas o gateway podia negar por indisponibilidade, conflito ou regra. Uso de endereço, tupla, destino ou túnel fora da concessão exigia descarte. O host escrevia a fonte pública; o gateway julgava se aquele uso pertencia a um grant vivo.

Por isso, uma auditoria precisa manter request e response, client ID, bind ID, recursos, lease, policy, route decision, tunnel, admissão e pacotes nos dois sentidos. “Atribuído” não resume a cadeia.

Localidade passou a exigir evidência

O mesmo host tinha agora duas representações. Para cada destino, precisava decidir se a entrega seria direta na rede privada ou se usaria a interface RSIP e o gateway. Uma máscara servia em uma topologia simples. Em redes maiores, a RFC 3102 sugeria que o gateway armazenasse redes privadas e respondesse a consultas.

Se as rotas mudassem mais rápido que a sessão, a informação envelhecia e o host talvez precisasse consultar cada destino. O documento registrou a incerteza: uma solução geral robusta havia se mostrado difícil, e a gravidade prática não era conhecida.

Aplicações multiparte expunham o conflito. Um participante podia repassar um endereço supondo ser um endpoint global, sem saber de qual realm o próximo o veria. O privado podia ser inalcançável externamente; o público podia obrigar vizinhos locais a contornar pelo gateway. Não havia solução geral conhecida.

O endereço, portanto, não carregava contexto suficiente. A posição do observador, a rota corrente e a política do host também faziam parte da decisão. RSIP explicitava o endereço emprestado, mas não criava uma noção universal de “local”.

O fim do lease não encerrava todos os estados

Um prazo limitava a autoridade e devolvia recursos escassos ao pool. O host podia estender ou liberar; o gateway podia deixar expirar ou desalocar. O relógio administrativo, porém, não apagava instantaneamente o transporte.

TCP podia manter uma tupla antiga em TIME_WAIT. Se endereço e porta fossem novamente emprestados cedo demais, pacotes atrasados ou proteções da conexão anterior poderiam encontrar o novo usuário. Expiração e reutilização segura eram eventos distintos.

Falhas também separavam memórias. Após reiniciar, o host podia esquecer binds ainda mantidos no gateway. Após a queda do gateway, o host podia acreditar em parâmetros que o servidor perdera. A RFC 3103 descrevia trocas para reconstruir a relação, mas nenhuma cópia unilateral era verdade completa.

O histórico útil inclui início, extensão, liberação ou expiração, reinícios dos dois lados e primeiro pacote aceito após reconciliação. O mesmo número pode pertencer a gerações diferentes de concessão.

Um endereço compartilhado não era uma identidade

Com RSA-IP, DNS dinâmico se parecia com DHCP: um host detinha o endereço inteiro por um período. Em RSAP-IP, diversos nomes podiam resolver para o mesmo endereço enquanto portas diferentes levavam a hosts diferentes. Um par público podia imaginar que todos os serviços naquele endereço pertenciam a uma só entidade. A RFC recomendava cautela ao combinar esse modo com DNS.

A RFC 3104 tornou a distinção decisiva em IPsec. Clientes RSIP compartilhando um endereço poderiam iniciar IKE e IPsec com um par que desconhecia RSIP. O endereço de origem visível não identificava o par real; identificadores IKE deveriam fazê-lo.

Respostas IKE podiam ser demultiplexadas por porta de destino, cookie do iniciador e endereço. AH ou ESP usavam protocolo, SPI e endereço de destino. O SPI precisava ser único tanto no cliente quanto no espaço compartilhado do gateway. O endereço era um localizador de chegada, não um principal criptográfico.

Ainda havia limites. O mecanismo se concentrava em sessões iniciadas pelo cliente, exigia cooperação da implementação IPsec e não prometia que um arranjo bump-in-the-stack funcionasse sem alteração. Transparência do pacote não equivalia à transparência da aplicação.

Descoberta escolhia o gateway; não concedia recursos

A RFC 3105 usava SLP para anunciar URL service:rsip, capacidades, lifetime e carga opcional. Scopes orientavam clientes a determinados servidores; um cliente podia preferir o gateway com menos conexões declaradas.

Mas scope não era controle de acesso. A propaganda dizia o que o servidor afirmava oferecer, não que o cliente seria aceito. A carga podia ficar desatualizada antes da conexão. Depois de descobrir, ainda era necessário registrar, receber um grant, instalar o caminho e observar tráfego.

As autoridades ficavam separadas. Administradores configuravam descoberta e scopes. O gateway aprovava recursos e policy. O host escolhia localidade e construía pacotes. O par remoto aceitava identidade e sessão. Só o tráfego de ida e volta mostrava o resultado combinado.

O valor de uma experiência que admitia seus custos

As RFCs 3102–3105 eram Experimentais, não Internet Standards. A nota do IESG alertava para mudanças significativas em host e gateway, problemas com portas flutuantes e complexidade operacional. O próprio framework dizia que RSIP não era solução duradoura para escassez IPv4. As fontes não provam adoção ampla nem substituição do NAT.

O episódio continua importante porque desdobrou o que um tradutor escondia: compartilhar endereço exigia registro, alocação, bind, lease, policy, discovery, recuperação e decisão de localidade. Levar o parâmetro público ao host tornava a distribuição de estado impossível de ignorar.

Um endereço emprestado mostrava onde o pacote pretendia aparecer. Não provava propriedade, identidade única, caminho correto, autenticação ou entrega. O gateway emprestava o localizador; apenas registros coerentes, estado em execução e pacotes nos dois sentidos faziam o empréstimo funcionar.

Fontes

  1. https://www.rfc-editor.org/rfc/rfc3102.html
  2. https://www.rfc-editor.org/info/rfc3102
  3. https://datatracker.ietf.org/doc/rfc3102/
  4. https://www.rfc-editor.org/rfc/rfc3103.html
  5. https://www.rfc-editor.org/info/rfc3103
  6. https://datatracker.ietf.org/doc/rfc3103/
  7. https://www.rfc-editor.org/rfc/rfc3104.html
  8. https://www.rfc-editor.org/info/rfc3104
  9. https://datatracker.ietf.org/doc/rfc3104/
  10. https://www.rfc-editor.org/rfc/rfc3105.html
  11. https://www.rfc-editor.org/info/rfc3105
  12. https://www.rfc-editor.org/rfc/rfc1631.html
  13. https://www.rfc-editor.org/rfc/rfc2663.html
  14. https://www.rfc-editor.org/rfc/rfc2993.html
  15. https://www.rfc-editor.org/rfc/rfc3022.html