Resumo

  • Na arquitetura HIP de 2006, Robert Moskowitz e Pekka Nikander propõem uma identidade baseada em chave pública para nomear o ponto final e mantêm o endereço IP como localizador para o encaminhamento.
  • A separação pode preservar uma associação após a troca de endereço se os dois hosts usam HIP. Ela não transfere um registro de recursos nem atualiza automaticamente as regras de todas as aplicações.

Um notebook sai de uma rede e recebe outro endereço IP. O caminho dos pacotes mudou; o host com que ele se comunica continua o mesmo. Durante muito tempo, os protocolos pediram que um único número representasse tanto uma localização topológica quanto o ponto final da comunicação. Robert Moskowitz e Pekka Nikander tornaram essa sobrecarga o problema central da RFC 4423.

O Host Identity Protocol cria um espaço de identidade entre a camada de Internet e a de transporte. Nessa arquitetura, o Host Identifier é uma chave pública, enquanto a Host Identity que ele representa é a entidade abstrata. O Host Identity Tag (HIT) oferece uma representação compacta de 128 bits. O endereço IP continua indispensável para que roteadores saibam para onde enviar pacotes. O que muda é a obrigação de usar esse endereço como única definição do host ao qual uma associação de transporte pertence.

Essa mudança de vínculo é o ponto decisivo. A RFC 4423 descreve associações de transporte vinculadas a Host Identities. Quando a mobilidade, uma nova conexão de acesso ou a renumeração muda o endereço, um par compatível com HIP pode atualizar o localizador e conservar a associação ligada à identidade. Um host também pode ser alcançado por várias interfaces. Parte da continuidade deixa, assim, de depender de um endereço fixo e passa a depender do estado criptográfico mantido pelas duas pontas que participam do protocolo.

A sequência das RFCs ajuda a delimitar a contribuição de Moskowitz. A RFC 4423 saiu em maio de 2006 como documento Informativo. O próprio resumo a descreve como um retrato do raciocínio dos autores no outono de 2003 e observa que a arquitetura poderia ter evoluído; ela não especifica um Internet Standard. A RFC 7401, editada por Moskowitz com outros autores, especifica o HIP versão 2 na trilha Standards Track. O texto descreve hosts que consentem em estabelecer estado compartilhado na camada IP por meio de uma troca criptográfica de quatro pacotes. Em 2021, a RFC 9063, de Moskowitz e Miika Komu, atualizou a arquitetura, tornou obsoleta a RFC 4423 e incorporou lições de implementações da RFC 7401, além de tratar de agilidade criptográfica e confiança no primeiro uso.

Essa evolução comprova que a proposta foi desenvolvida; não comprova que a Internet deixou de depender de endereços. O HIP preserva a associação administrada pelos dois extremos participantes. Um firewall pode continuar liberando apenas um IP de origem. Uma entrada DNS pode apontar para o endereço antigo. O outro host talvez não implemente HIP. Uma aplicação pode guardar o IP em uma configuração ou usá-lo como sinal de reputação. Manter uma associação durante a mudança não atualiza automaticamente nenhum desses elementos.

Nota 68 de Heng Lu oferece outra lente econômica: o endereço pode virar memória empresarial quando clientes, parceiros e equipes de segurança constroem expectativas em torno dele. Isso não descreve o HIP nem demonstra uma implantação específica. Ajuda a separar duas continuidades. O HIP distingue a identidade do host usada na troca de protocolo do localizador usado pelo roteamento; não reescreve as relações externas que se acumularam em torno de um endereço.

A contribuição de Moskowitz pode ser lida como uma fronteira de arquitetura: “minha rota pode mudar; minha identidade autenticada como ponto final é outro estado”. A fronteira é útil justamente por ser delimitada. O HIP pode reduzir a dependência de endereços fixos em mobilidade e multihoming, mas deixa DNS, roteamento, administração de recursos, políticas de aplicação e compromissos de continuidade com clientes em seus próprios sistemas.

Fontes