RFC 7021 is an Internet standards document that specifies host identity semantics for IPsec mobility and multihoming using the Host Identity Protocol family. It separates a stable host identity from changing IP addresses so secure associations can survive network changes.
How RFC 7021 Works
RFC 7021 defines a host identity model that sits between a device and its changing network location. Instead of treating the IP address as the long-term anchor for trust, the document preserves a stable host identity so security associations can continue across mobility and multihoming events.
This matters because secure communications often break when the network path changes. By separating identity from location, the protocol family gives peers a way to recognise the same host after address changes, interface shifts, or path failover without renegotiating trust from scratch.
Why Host Identity Semantics Matter
The core design goal is continuity. In ordinary IP networking, an address can function as both locator and implicit identifier, which becomes fragile when a host roams or uses multiple interfaces. Host identity semantics reduce that coupling, making the trust relationship more stable than the transport path.
That distinction is especially useful where long-lived sessions, policy decisions, or peer reputation need to survive renumbering. It also makes the security story more explicit: the subject of trust is the host identity, while the IP address is just the current route to reach it.
Security Properties and Trust Boundaries
RFC 7021’s security value comes from stabilising the endpoint relationship while the network changes underneath it. That can reduce disruption, but it also shifts attention to how host identity is bound, authenticated, and managed, because a stable identity becomes a high-value trust anchor once it is reused across multiple paths.
The model is strongest when identity binding is tightly protected and weak when that binding can be forged, replayed, or confused with a temporary address. In practice, the trust boundary moves from “which IP am I seeing now?” to “can I still verify that this is the same host I trusted before?”
For background on the standards body and RFC publication workflow, see the IETF and the IETF Datatracker.
Operational Uses in Mobility and Multihoming
In mobility, the same host may move across networks without losing the security context attached to it. In multihoming, a host may present several active paths at once, and the protocol family helps keep those paths associated with one stable identity rather than treating each address as a separate peer.
That makes the approach useful for continuity, failover, and path resilience, but it also means operators need to think about lifecycle and governance for host identities. If the identity is too easy to copy, too long-lived, or poorly retired, the benefit of stable trust can turn into durable misuse.
If you want to verify an RFC’s status, adoption history, or related drafts, the IETF Datatracker is the most direct reference point.
Risk and Threat Considerations
Host identity schemes reduce session breakage, but they also create a more durable trust target. If the identity binding, keying material, or update path is compromised, an attacker can try to impersonate a trusted host, redirect traffic, or keep access alive across address changes.
Failure mechanism: Weak binding between stable identity and current network location can allow spoofing, hijacking, or trust confusion when a host moves or fails over.
Impact: Security associations may survive in the wrong hands, extending access, preserving sessions after compromise, or sending traffic to an untrusted endpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Host identity semantics depend on reliable peer authentication across changing network paths. |
| IA-5 — Authenticator Management | Stable host identity depends on protected credentials and lifecycle control for the trust anchor. | |
| SC-23 — Session Authenticity | The term is about preserving a secure association as the network location changes. | |
| Recommendation — Bind host identity to strong authentication so mobility does not weaken peer trust. Manage credentials and rotation so host identity remains trustworthy during address changes. Validate session authenticity so roaming or multihomed hosts cannot be confused with impostors. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Separating identity from network location aligns with verifying the subject of trust rather than the path. |
| Recommendation — Apply identity-centric verification so changing IP addresses do not become implicit trust signals. | ||
Practitioner Guidance
Governance implication: Treat host identity as a managed trust object, not just a protocol convenience. Ownership, enrollment, rotation, and retirement matter because the same identity may remain valid across many addresses and network paths.
What to watch for: Review whether your implementation can distinguish a legitimate mobility event from an unauthorized identity reuse event. The operational question is not only whether the connection survives, but whether it survives for the right host.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org