Host Identity Protocol RFC 7401: Lessons for IPvX Addresses

Host Identity Protocol RFC 7401 is useful to us as a published IETF example of a protocol that separates the identifier role from the locator role of IP addresses and establishes shared IP-layer state between consenting hosts.² HIP uses public-key identifiers from the Host Identity namespace for mutual authentication of participants and is based on a Diffie-Hellman exchange.² For the design of IPvX addresses, this is not a ready-made blueprint, but a set of architectural questions that have already been explicitly formulated in IETF documents on HIP.¹

Why separating identifier and locator matters

RFC 7401 describes HIP as an alternative to the dual use of IP addresses: IP addresses can act both as locators, meaning routing labels, and as identifiers, meaning identifiers of hosts or endpoints.³ In HIP, public cryptographic keys from a public/private key pair are used as host identifiers, and higher-layer protocols are bound to these identifiers instead of being bound to an IP address.³

RFC 9063 frames the same problem more broadly: the Internet has two important global namespaces — IP addresses and DNS names — and both spaces have become semantically overloaded because of attempts to make them do too much.¹ In the HIP architecture, the Host Identity namespace is added between the IP and DNS namespaces, and the corresponding protocol layer is located between the internetworking and transport layers.¹

For IPvX, we draw a cautious lesson from this: key-based addressing should not automatically conflate cryptographic identity, the representation of that identity in packets, and the current delivery path.³ This is our design interpretation of HIP, not a requirement that RFC 7401 imposes on IPvX.³

Key, identity, and compact tag are different entities

RFC 9063 distinguishes between Host Identity and Host Identifier: Identity refers to the abstract entity being identified, while Identifier is the specific bit pattern used in the identification process.¹ In the focal case of the HIP architecture, the Host Identifier is the public key of an asymmetric pair.¹

HIP also defines the Host Identity Tag, or HIT, as a 128-bit value obtained by cryptographically hashing the Host Identifier and adding bits that indicate the hash used.¹ In the terminology of RFC 9063, the Host Identity Hash is the cryptographic hash used when creating a HIT from a Host Identifier.¹ The document also defines a Local Scope Identifier as a 32-bit value that denotes a Host Identity within a local scope.¹

These definitions give us a useful vocabulary discipline for IPvX: “key,” “abstract identity,” “compact tag,” and “local scope identifier” are not the same concept in HIP.¹ We can use this discipline when describing IPvX addresses, but we should not present it as a direct prescription from RFC 9063 for IPvX.¹

The history of HIT also shows that the format of a compact representation can evolve.⁶ In RFC 4423, a HIT was described as a 128-bit value created by hashing a Host Identifier.⁶ In RFC 9063, the definition of HIT already includes bits that indicate the hash used.¹ This does not prove what the IPvX address format should be, but it shows that in HIP, the algorithmic context of a compact tag became part of the architectural description.¹

Base Exchange as a model for establishing state

RFC 7401 defines the base HIP protocol, or base exchange, used between hosts to establish an IP-layer communications context, called a HIP association, before communication.³ The contents of RFC 7401 separately list the creation of a HIP Association, the HIP Puzzle Mechanism, puzzle exchange, authenticated Diffie-Hellman with DH group negotiation, replay protection, aborting the base exchange, interrupting the base exchange, downgrade protection, and opportunistic mode.²

The RFC 7401 specification also lists the control packets I1, R1, I2, R2, UPDATE, NOTIFY, CLOSE, and CLOSE_ACK.² The same document includes sections on updating a HIP association, error processing, the HIP state machine, processing UPDATE with SEQ and ACK, processing CLOSE and CLOSE_ACK, and handling state loss.²

For IPvX, this set of topics is useful as a connection-design checklist, but not as proof that IPvX must replicate the HIP state machine.² We can test our own design against the same classes of questions: how an association is created, how parameters are negotiated, how errors are detected, how state is updated, and how communication is closed.² At the same time, a claim about a “cheap start” should not be inferred from RFC 7401 alone; the source directly confirms the existence of a puzzle mechanism and protective sections, but does not formulate a universal requirement for any key-based addressing protocol.²

Payload security and associations are separate layers

RFC 7401 says that HIP designed to be resistant to denial-of-service and man-in-the-middle attacks.² The document also states that when used with a suitable security protocol, such as ESP, HIP provides integrity protection and optional encryption for upper-layer protocols such as TCP and UDP.²

RFC 9063 clarifies the architectural role: when HIP is used, the payload between HIP hosts is typically, but not necessarily, protected by Encapsulating Security Payload, while Host Identities are used to create the necessary ESP Security Associations and authenticate the hosts.¹ This is an important boundary for IPvX: key-based addressing can be part of authentication, but payload protection, security association parameters, and the lifecycle of such associations require a separate description.¹

The HIP documents also show that cryptographic flexibility was a subject of explicit adjustment.² RFC 7401 reports that the document addresses IESG comments, particularly on crypto agility, and incorporates lessons from implementations of RFC 5201.² RFC 9063 also says that it takes into account concerns raised by the IESG, particularly crypto agility.¹ For IPvX, this is not a ready-made rule about specific hashes or key types, but it is a strong reason to explicitly document the algorithmic context of addresses and the procedure for format evolution.¹

Rendezvous, mobility, and address changes

One of HIP’s central properties in RFC 7401 is maintaining communication continuity when IP addresses change by separating the identifier and locator roles.² RFC 9063 describes the HIP layer as supporting end-host mobility, multihoming, and NAT traversal.¹

In RFC 9063 terminology, a Rendezvous Mechanism is a mechanism for finding mobile hosts by their HIT.¹ In RFC 4423, the rendezvous mechanism was likewise defined as a mechanism used to find mobile hosts by Host Identity Tag.⁶

For IPvX, this suggests a cautious formulation of the lesson: a stable key-based identifier does not by itself describe where the recipient is currently located.¹ If a protocol wants to preserve identity while the delivery path changes, it needs a separate way to associate the identifier with a current locator or route; HIP calls this class of task a rendezvous mechanism.¹

It is important not to overstate this conclusion.² RFC 7401 confirms the existence of UPDATE, SEQ, and ACK procedures for processing HIP association updates, but this does not imply an automatic scaling rule for IPvX.² We can use HIP as an example showing that changes to association state are separated into distinct procedures, but IPvX fault-tolerance and scaling parameters must be tested through our own experiments.²

Certificates: extensibility without overloading the first packet

RFC 8002 updates RFC 7401 and defines the CERT parameter as a container for digital certificates in HIP control packets.⁵ The same document emphasizes that the CERT parameter does not define the semantics of certificates, and that specific use cases must be defined by documents that apply this parameter.⁵

This is a good example of separating mechanism from trust policy.⁵ A base protocol can describe certificate transport, grouping related CERT parameters, and error signaling when validation fails without embedding every scenario-specific decision into a single universal format.⁵

RFC 8002 also contains a negative lesson: using CERT in the first Initiator packet I1 is not recommended, because it may increase the processing time of I1 and become a problem during processing storms of I1s.⁵ For IPvX, we can formulate this as a design hypothesis: proofs, certificates, and attestations should not automatically be placed in the earliest and most widely generated handshake packet.⁵ This is specifically an inference for our design, not a quoted requirement from RFC 8002 for IPvX.⁵

RFC 8002 also describes options for transmitting pointers instead of the certificates themselves: Hash and URL, LDAP URL, and Distinguished Name can reduce HIP control packets, but require the recipient to resolve the URL, obtain the certificate, or check a local cache.⁸ Therefore, when designing the IPvX handshake, the trade-off between a self-contained message and dependence on external retrieval of trust data must be considered separately.⁸

Documenting maturity and limitations

RFC 4423 was an informational document and explicitly described itself as a snapshot of thinking about the HIP architecture in the fall of 2003.⁶ RFC 4423 also said that the architecture may have changed and that the document represents one stable point in the evolution of understanding.⁶ This example matters for a research protocol: the document’s status and the maturity level of the architecture should be visible to the reader.⁶

RFC 9063 replaced RFC 4423 and remained an Informational-category document, while RFC 7401 is a Standards Track document with Proposed Standard status.⁴ This shows that an architectural description and a base protocol specification can have different statuses in the IETF process.⁴

Security Considerations in RFC 9063 include flooding attacks, use of identities in access control lists, weaker types of identifiers, and trust on first use.¹ The appendices to RFC 9063 also include design considerations, benefits, drawbacks, deployment and adoption considerations, deployment analysis, infrastructure applications, and management of identities in a commercial product.⁴ For our IPvX RFC projects, this supports the practice of explicitly separating the packet format from limitations, operational assumptions, and known trade-offs.⁴

The history of RFC 7401 in Datatracker records publication of the RFC on April 9, 2015, and updates to IANA registries on April 10, 2015.⁷ The same history shows later RFC Editor metadata synchronizations, including abstract changes in 2018, the addition of the Verified Errata tag in 2020, and metadata updates in 2026.⁷ This does not prove the existence of all subsequent updating RFCs, but it does show that the public record for the document continues to be maintained after publication.⁷

What we take into IPvX

The first lesson: when describing IPvX addresses based on keys, it is useful to explicitly distinguish between abstract identity, a public key as an identifier, a compact hashed representation, and the current locator, because HIP distinguishes between Host Identity, Host Identifier, HIT, and the locator role of an IP address.¹³

The second lesson: connection establishment should be designed as a state lifecycle, not as a single key exchange, because RFC 7401 describes the HIP association, base exchange, state machine, UPDATE, NOTIFY, CLOSE, CLOSE_ACK, and handling state loss.²

The third lesson: rendezvous should be treated as a separate control-plane task, because RFC 9063 defines a mechanism for finding mobile hosts by HIT and connects the HIP architecture with mobility, multihoming, and NAT traversal.¹

The fourth lesson: certificates and additional proofs should be separated from the base semantics of the address, because RFC 8002 defines the CERT parameter as a container and leaves scenario-specific semantics to the documents that use this parameter.⁵

The fifth lesson: limitations, negative results, and the history of decisions should be part of our drafts, because the HIP documents explicitly show maturity status, security considerations, drawbacks, and deployment considerations.⁴⁶

The conclusion for us is cautious: HIP does not define IPvX and does not relieve us of the obligation to test routing, failures, and scaling in our own reproducible experiments.² But HIP provides a published language for discussing key-based addresses, security associations, rendezvous, mobility, and the boundaries between architecture, specification, and operational limitations.¹²

Sources

1. RFC 9063: Host Identity Protocol Architecture, rfc-editor.org, Jul 1, 2021
2. RFC 7401: Host Identity Protocol Version 2 (HIPv2), datatracker.ietf.org
3. RFC 7401: Host Identity Protocol Version 2 (HIPv2), datatracker.ietf.org
4. RFC 9063: Host Identity Protocol Architecture, datatracker.ietf.org
5. RFC 8002: Host Identity Protocol Certificates, datatracker.ietf.org
6. RFC 4423: Host Identity Protocol (HIP) Architecture, datatracker.ietf.org
7. History for rfc7401, datatracker.ietf.org
8. RFC 8002: Host Identity Protocol Certificates | RFC Editor, rfc-editor.org