Summary

  • Robert Moskowitz and Pekka Nikander’s 2006 HIP architecture treated a public-key identity as the endpoint name and left the IP address to locate that endpoint for packet delivery.
  • This separation can support an association surviving an address change when both hosts use HIP. It does not transfer an address registration, update every application’s access rules, or promise universal continuity.

A laptop leaves one network and receives a new address. The route to it has changed; the machine at the other end has not. Internet protocols have often asked one number to carry both facts. That was the design problem Robert Moskowitz and Pekka Nikander made explicit in RFC 4423: an IP address describes a topological location, but it also gets treated as the name of the communicating endpoint.

Their proposed Host Identity Protocol (HIP) inserted a separate identity layer between internetworking and transport. In the architecture, a Host Identifier is a public key. The document distinguishes that concrete key from the abstract host identity it represents. HIP uses a fixed-length Host Identity Tag (HIT), a 128-bit hash of the identifier, in protocol state. An IP address remains useful—it tells routers where packets should go—but it no longer has to define which host owns the transport association.

That change in binding is the central idea. RFC 4423 describes transport associations as tied to Host Identities. If an address changes through mobility, a new network attachment or renumbering, a HIP-aware peer can update the locator while retaining the identity-bound association. The same logic can support more than one interface for a host. In practical terms, HIP moves one source of continuity from the address to cryptographic state shared by the participating endpoints.

Moskowitz’s role should be read through the standards record, not through the title alone. RFC 4423 was published in May 2006 as an Informational document. Its own abstract calls it a snapshot of the authors’ reasoning as of Fall 2003 and says the architecture may have evolved; it explicitly does not specify an Internet Standard. The later RFC 7401, edited by Moskowitz with other authors, specifies HIP version 2 as a Standards Track protocol. It describes consenting hosts establishing shared IP-layer state and a four-packet exchange that authenticates the endpoints. The still later RFC 9063, coauthored by Moskowitz and Miika Komu, updates the architecture and obsoletes RFC 4423, incorporating lessons from implementations of RFC 7401 and addressing questions such as cryptographic agility and trust on first use.

That sequence is evidence of a technical idea being revised, not evidence that address dependence disappeared from the Internet. HIP’s continuity applies to the association its endpoints manage. A customer system may still allow traffic by source IP. A DNS record may still point to an old address. A peer may not speak HIP. An application may persist an address in configuration or use it as a reputation signal. None of those dependencies is migrated simply because a transport association has a stable cryptographic identity.

Note 68 by Heng Lu offers a useful but separate economic lens: an address can become business memory when customers, partners and security teams build expectations around it. That observation does not describe HIP or prove a particular deployment. It clarifies why the two forms of identity should not be collapsed. HIP separates the host identity used by a participating protocol exchange from the locator used for routing; it does not rewrite the external relationships that may have accumulated around an address.

Moskowitz’s contribution is therefore best understood as a boundary design. It gives networked hosts a way to say, in effect, “my route may change; my authenticated endpoint identity is a different piece of state.” The boundary is powerful precisely because it is narrow. It can make mobility and multihoming less dependent on fixed addresses, while leaving naming, routing, resource administration, application policy and customer-facing continuity to their own systems.

Sources