Summary

  • RFC 5338 lets a HIP-aware host place an LSI or HIT where a legacy application expects an IP address. That preserves the old socket shape; it does not grant the value global address authority.
  • Keep local allocation, Host Identity mapping, current locator, path selection, HIP association, application result and audit correlation as separate receipts.

The bug begins when shape becomes jurisdiction

On host A, a resolver returns 1.x.y.z-shaped bits to an old application. The HIP layer knows that those bits mean a particular Host Identity. connect() works because the same host owns the mapping table. The application then includes that value in a callback message sent to host B. B sees a syntactically ordinary address. It does not possess A's mapping.

That is not an exotic corner case. RFC 5338 divides legacy address use into short-lived handles, long-lived associations, callbacks, referrals and identity comparisons. A local compatibility token can work perfectly in the first role and fail dangerously in the next four. The visible type did not change. The authority behind it did.

This is the central operational lesson of the RFC. Compatibility preserves an interface, not every assumption accumulated around that interface. An address field may now carry a host-identity handle, while the application still believes it carries a routable location. The system has borrowed the field's syntax without inheriting its global semantics.

An LSI is an entry in one machine's table

RFC 5338 defines a Local Scope Identifier as a 32- or 128-bit quantity that locally represents a Host Identity at the IPv4 or IPv6 API. The later HIP architecture in RFC 9063 makes the boundary sharper: the common 32-bit LSI is translated to and from HITs by the HIP layer or socket handler and is never transmitted on the wire as the locator.

The most useful mental model is not “special IP address”. It is “index into local state”. To interpret it, an operator needs the allocating host, mapping epoch and bound HIT or Host Identifier. Without those coordinates, the bits have no durable subject. Another host can reject them, interpret them as ordinary routing data, or map the same value to a different identity.

This is why a successful local connection proves so little about portability. It proves that the producing host could resolve its own handle at that moment. It does not prove that a referral recipient can do so, that the mapping survives restart, that the handle was not recycled, or that a log collector can recover the original association later.

DNS can return a handle without creating a global name

RFC 5338 describes a local DNS agent that obtains HIP identity information and returns an LSI or HIT to an unaware application. The system keeps the mapping and converts at the system-call boundary. The application proceeds as though it received an address.

The chain contains several independent acts. A directory supplied identity material. A local resolver chose a representation. A local table allocated a handle. Later, a socket call consumed that handle. Current locators still had to be found. A HIP association still had to be established. Protected packets still had to flow. The application still had to finish its work.

Collapsing those acts creates false receipts. “DNS resolved” does not mean “the LSI is globally resolvable”. “The LSI was accepted by connect()” does not mean “the intended peer authenticated”. “HIP was attempted” does not reveal whether the application raced a conventional IP connection and completed that path first.

RFC 5338 explicitly considers mixed resolver lists. HIP identifiers may appear first, but some applications launch attempts in parallel. A non-HIP attempt may win. List order is policy input, not path-selection evidence. A system that requires HIP may need to return only HIP identifiers rather than assuming the application will respect preference.

Referrals export bits and strand meaning

A referral is where the local boundary becomes visible. Party B takes the address of party A and gives it to party C. With an ordinary globally meaningful address, that can sometimes work. With B's LSI for A, C receives an index into a table it does not own.

The dangerous failure is not always a clean error. A clean error is diagnosable. More troubling is accidental reinterpretation: the value falls inside a range treated as ordinary IPv4, or C has independently allocated the same LSI to another Host Identity. The callback then targets the wrong authority while every field remains syntactically valid.

The proper repair is architectural. Application protocols should carry a name with the scope and resolution rules needed by the receiver. If a local handle must appear in telemetry or inter-process state, it needs explicit scope: allocating node, namespace, mapping epoch and the authoritative Host Identity. Copying a bare LSI across that boundary is equivalent to copying a database row number without the database name.

RFC 9063 compares the problem to host-based NAT. The analogy is useful because it refuses magical thinking. A translation boundary can preserve old applications, but applications that embed local addresses into protocols were already vulnerable to changed scope. HIP does not cause the layering violation; it exposes it.

Caches turn a temporary handle into a false history

Legacy applications may cache resolver answers for much longer than the HIP implementation expects. RFC 5338 notes that this complicates garbage collection of LSI bindings. The system cannot safely reuse an identifier merely because its own timer expired if a process may still hold the old value.

That creates an audit problem as well as a runtime one. Suppose an LSI belonged to Host Identity X in the morning and, after restart or collection, to Y in the afternoon. A log line containing only the LSI cannot answer which host a request concerned. A later join against the current mapping actively fabricates history.

The minimum durable record is a tuple, not a token: event time, local host, process or socket, LSI, HIT or Host Identifier, observed locator, FQDN context, mapping generation, and the operation performed. RFC 5338 recommends logging HITs, LSIs, corresponding IP addresses and FQDN-related information precisely so operators can correlate HIP events with other logs.

Even that tuple does not prove application success. It records what the compatibility layer believed and selected. Association completion, protected data and business outcome need their own events. The discipline is to preserve the chain without allowing the most address-like field to impersonate the rest.

connect(ip) may authenticate less than the interface suggests

RFC 5338 distinguishes transparent policy based on an ordinary IP address from explicit connection to a HIT. If an application says only connect(ip), the strongest safe reading may be “connect to the system currently reachable at this address”. The host can try HIP and gain forward secrecy and cryptographic authentication within the resulting exchange, yet the initial application request did not itself strongly name the peer.

An explicit HIT is different. It asks the system for a particular cryptographic host name and cannot be treated as an ordinary routable address. But the stronger name is still not an end-to-end outcome receipt. The system must resolve locators, complete the base exchange, establish the relevant protection, deliver traffic and obtain an application response.

This separation keeps RFC 5338 distinct from other HIP controls. The issue here is not whether an RVS relayed an I1, whether a DNS HIP record is fresh, whether a locator was verified, or whether ESP crossed a firewall. It is whether the value crossing a legacy API carries local-handle, locator or identity authority—and whether that authority survives the next boundary.

Wildcard servers expose the same ambiguity in reverse

The legacy problem is not limited to clients. A server may bind a wildcard address while the host owns multiple Host Identities. Local policy then chooses which HI represents a connection. RFC 5338 describes a UDP case where recvfrom() receives under one expectation but sendto() selects a different server HIT; a client enforcing socket-level identity can discard the response.

A successful bind therefore does not prove that every response will preserve the identity the peer addressed. A wildcard is an admission surface, not a deterministic identity-selection receipt. If the application binds to a particular HIT, the system should enforce that only connections for that HIT reach it. When the application cannot express that intent, the operator must narrow what is advertised or record the policy decision explicitly.

The common pattern is the same: legacy interface success hides a choice made below the application. Reliability depends on making that choice observable and keeping it scoped to the authority that actually made it.

Sources and evidence boundary

The sources establish specifications, historical experiment reports and declared architecture. They do not establish a current product, deployment, incident, adoption rate, affected organisation or measured failure.