Resumo

  • Um LSI é uma representação local de Host Identity dentro da pilha que mantém o mapeamento; seu formato compatível com IPv4 não cria uma referência portátil.
  • Cache, logs e referrals precisam preservar host, época, HIT e contexto de resolução, deixando caminho, associação HIP, tráfego protegido e resultado em recibos separados.

A expiração do mapeamento não apaga o aplicativo

Uma pilha HIP aloca um LSI para um peer. O aplicativo resolve o nome, usa o valor e o guarda em cache. Mais tarde, a pilha coleta a entrada. Talvez o host reinicie; talvez o identificador seja reutilizado. O aplicativo continua com a mesma sequência de bits e acredita possuir o mesmo destino.

RFC 5338 reconhece que aplicativos podem reter respostas DNS por muito tempo, tornando difícil escolher quando liberar os bindings LSI. O conflito não é apenas de memória. É uma disputa entre dois relógios: a validade operacional da tabela e a expectativa de duração embutida no software legado.

Se o número for reutilizado, o próximo connect() pode buscar outra Host Identity. Se o número aparecer em um log histórico, uma consulta à tabela atual pode atribuir o evento ao sujeito errado. Em ambos os casos, o erro nasce da mesma promoção: um handle temporário foi tratado como nome permanente.

O formato IPv4 é uma embalagem local

RFC 5338 define LSI como quantidade de 32 ou 128 bits que representa localmente uma Host Identity na API IPv4 ou IPv6. RFC 9063 explica que o LSI típico de 32 bits é convertido para HIT pela camada HIP ou pelo manipulador de sockets e não é transmitido no fio como localizador.

Isso muda a pergunta operacional. Não se deve perguntar “qual rota leva ao LSI?”, mas “qual tabela, em qual host e em qual geração, interpreta esse LSI?”. A rota pertence ao localizador encontrado depois. A identidade pertence ao HIT ou HI. O LSI apenas permite que um programa antigo atravesse a interface sem aprender os novos tipos.

O sucesso dessa travessia não aumenta o escopo. Um valor aceito pelo socket local não se torna automaticamente compreensível por outra máquina, por um serviço de logs ou por uma base de dados de longa duração. O contrato termina onde termina o intérprete.

O resolvedor pode esconder HIP sem provar que HIP venceu

Um agente DNS local pode obter informação de identidade e devolver LSI ou HIT ao aplicativo. A pilha conserva a correspondência e faz a conversão. Esse desenho permite adoção incremental, mas produz eventos que precisam ser nomeados com precisão.

Houve descoberta de identidade. Houve alocação de um handle. Pode ter havido descoberta de localizador e tentativa de associação. Nada disso, isoladamente, prova que a associação terminou, que pacotes protegidos seguiram por ela ou que o serviço respondeu.

O resolvedor também pode retornar uma lista mista, colocando identificadores HIP antes de endereços comuns. Alguns aplicativos percorrem a lista; outros iniciam conexões paralelas. Nesse segundo caso, a conexão não-HIP pode terminar primeiro. A ordem da lista representa preferência, não execução.

Uma exigência de uso de HIP precisa controlar candidatos ou registrar a tentativa vencedora. Auditoria baseada apenas na resposta do resolvedor confunde política pretendida com caminho observado. Essa diferença é especialmente importante quando segurança e conformidade dependem do canal realmente usado.

Referral exige autoridade compartilhável

Considere três partes. B alcança A usando um LSI e passa esse “endereço” a C. C não recebeu a identidade de A nem a tabela de B; recebeu um índice local. O fato de o campo aceitar quatro bytes não resolve a falta de autoridade.

O resultado pode ser rejeição, interpretação como endereço comum ou colisão com um LSI que C atribuiu a outro peer. A colisão é a situação mais traiçoeira, pois a operação parece tecnicamente válida e pode chegar ao sujeito errado.

Um protocolo de referral deve transportar algo que C consiga resolver no seu próprio contexto: um HIT com mecanismo apropriado, um nome com política de validação ou um objeto que declare identidade, emissor, alcance e validade. Se um intermediário traduz o LSI, o recibo deve dizer que houve mediação. O proxy não torna o identificador global; ele fornece contexto por conta própria.

RFC 9063 compara o problema à tradução de endereços no host. Aplicativos que embutem endereços locais em mensagens já sofrem com NAT. A conclusão não é abandonar compatibilidade, mas impedir que uma representação local seja vendida como contrato entre sistemas.

Logs precisam registrar a época, não só o valor

RFC 5338 recomenda que software HIP registre HITs, LSIs, endereços IP correspondentes e informação relacionada ao FQDN. Sem esse conjunto, administradores encontram números familiares que não conseguem correlacionar com os pacotes ou com a identidade.

Para uso forense, o conjunto precisa ainda de host alocador, boot ou geração de mapping, horário, processo, socket, decisão de política e ciclo de vida. Um log só com o LSI é semelhante a guardar o número de uma cadeira sem guardar a sessão em que os lugares foram distribuídos.

Mesmo um log rico tem limite. Ele prova como a camada local interpretou o handle. Não prova que a associação HIP chegou ao fim, que o peer manteve a chave naquele instante, que o fluxo protegido carregou a operação ou que o serviço a aceitou. Cada camada emite seu próprio recibo.

A prática segura correlaciona esses recibos por identificadores e tempo sem fundi-los. Assim, uma falha pode ser localizada: resolução, alocação, rota, associação, dados ou aplicação. Um campo genérico success=true apaga exatamente a informação necessária à explicação.

Um HIT explícito nomeia melhor, mas não entrega por si só

RFC 5338 distingue uma aplicação que pede connect(ip) de uma que fornece explicitamente um HIT. No primeiro caso, a intenção pode ser apenas alcançar o sistema disponível naquele IP. A política local pode adicionar HIP, mas o vínculo inicial com a Host Identity é fraco e invisível para o aplicativo.

O HIT expressa uma identidade criptográfica específica. É um pedido mais forte. Ainda requer resolução de localizadores, estabelecimento da associação, instalação do estado relevante, tráfego e resposta de aplicação. Nomear o peer não reserva capacidade nem concede autorização de serviço.

Esse é o recorte próprio deste artigo. Ele não repete se RVS encaminhou I1, se um registro HIP no DNS continua atual, se um locator de mobilidade foi verificado ou se ESP passou pelo firewall. Ele pergunta que tipo de autoridade um valor com formato de endereço carrega ao atravessar uma API legada.

O servidor wildcard deixa a identidade a cargo da política

Um servidor antigo costuma fazer bind em endereço curinga. Se o host tem várias Host Identities e a aplicação não escolhe uma, a política local seleciona a identidade usada. No caso UDP citado em RFC 5338, recvfrom() e o sendto() posterior podem terminar com HITs diferentes; um cliente que controla identidade no socket pode descartar a resposta.

O bind prova que existe um listener, não que a identidade será preservada na volta. A observabilidade deve registrar o HIT local de entrada, o HIT de saída e a regra que fez a seleção. Se a aplicação não trata multidentidade, a alternativa é anunciar apenas a identidade compatível com o caminho de saída padrão.

Compatibilidade não exige invisibilidade operacional. Ao contrário: quanto menos o aplicativo consegue expressar, mais a camada inferior precisa deixar recibos sobre suas decisões.

Fontes e limite das evidências

As fontes comprovam especificações, arquitetura declarada e um relatório histórico de experimentação. Não comprovam produto atual, implantação, incidente, organização afetada nem frequência de falha.