Summary

  • RFC 5206 and its Standards Track successor RFC 8046 authenticate a peer's locator announcement but normally place a newly learned address in UNVERIFIED state until a nonce reply or qualifying protected traffic proves reachability there.
  • Credit-Based Authorization may carry a limited number of bytes on the provisional route. It controls amplification; it does not turn the route into verified evidence or prove application continuity.

One packet, two questions

HIP separates a host identity from the IP address currently used to reach it. That is the architectural benefit: a transport association need not become a new identity merely because a device moves. It also creates an evidence problem. When the peer sends a signed UPDATE containing a new locator, the receiver learns two different things at once only if it is careless.

The first fact is strong: the update belongs to the cryptographic context of the HIP association, subject to the named algorithms, sequence state and validation result. The second fact is only a claim: the peer says it can be reached at a particular network attachment point. Signature validity does not make routers deliver there, prove that an interface is up, or show that the peer received a packet at that address.

RFC 5206 makes this boundary executable. RFC 8046 retains it while replacing LOCATOR with LOCATOR_SET for HIPv2. The receiver stores an address as UNVERIFIED, ACTIVE or DEPRECATED. A newly learned address normally begins in the first state. A product that jumps directly from signed to reachable erases the protocol's most important state transition.

The receipt travels to the claimed place

A typical reachability check places a random nonce in an ECHO_REQUEST carried by an UPDATE sent to the new address. The peer must receive it there and return the corresponding response. Other exchanges are allowed, but they must establish the same fact: receipt and reply at the new address.

The successor specification also permits protected data arriving on a newly advertised Security Association to count as implicit verification. That is not a shortcut back to the signature. It is an observation on the new path: traffic tied to the association arrived under the expected state. The evidence is the received packet, its authentication result, SPI context and time—not the presence of the address in an earlier message.

This distinction matters during rekeying. ESP_INFO can create or change Security Association state while LOCATOR_SET names where that state may be used. A created SA is readiness at one endpoint. A returned nonce or protected packet is evidence about the path. The first useful application exchange is another fact again.

Preference is not activation

The preferred bit says where the peer would like traffic to go. It is policy input, not a measurement. If a new preferred locator is still UNVERIFIED, RFC 8046 says an available ACTIVE locator should continue to carry communications while the test runs. Only after verification should the new locator become ACTIVE.

There is a narrow R1 rule in the base exchange, and RFC 5206 contains generation-specific details, but exceptions must not become a generic dashboard shortcut. The durable operating model is explicit: record why an address entered a state, which rule authorized the transition and which observation completed it.

A locator lifetime needs the same discipline. It tells the receiver how long the locator record may remain usable under the protocol. It does not guarantee that the attachment, route, NAT mapping, radio, interface or peer remains available for the entire interval. State can be valid inside the table and stale outside it.

Why packets may move before certainty

Waiting for a full round trip can interrupt a mobile application. Credit-Based Authorization addresses that cost. It measures recent bytes received from the peer and permits a bounded amount of traffic to the new, unverified locator. The counter falls as packets are sent and ages over time.

The mechanism is deliberately modest. It makes redirection-based amplification unattractive because a peer cannot cause more redirected traffic than the recent traffic on which its credit rests. It does not eliminate flooding, prove the new address belongs to the peer, or declare the route active. The specification says uncertainty can be managed under a budget; it does not say uncertainty vanished.

An honest telemetry record therefore reports sent under CBA rather than verified. It includes starting credit, received bytes that earned it, aging parameters, bytes spent, locator state and the eventual verification result. If the nonce never returns, the provisional traffic remains provisional evidence.

An operational chain that cannot lie by compression

The minimum receipt for a mobility event should keep these steps independent:

  1. established HIP association and validation context;
  2. UPDATE sequence, exact locator set, lifetime and preferred bit;
  3. legal-address and supported-locator checks;
  4. initial UNVERIFIED state and any retained ACTIVE alternative;
  5. challenge nonce, destination, send time and retransmissions;
  6. response or qualifying protected packet received on the new path;
  7. transition to ACTIVE and preferred-locator decision;
  8. SA installation and first accepted protected payload;
  9. application continuity, latency and loss;
  10. expiry, deprecation and removal of replicated state.

These are not ten ways to say “mobility succeeded.” They are ten opportunities to preserve the point at which evidence could stop. A signed update may pass while the challenge fails. The challenge may pass while a middlebox blocks later ESP. Protected packets may arrive while the application stalls. Each failure belongs to a different owner.

Historical status is part of the control

RFC 5206 was Experimental in 2008 and is obsolete. RFC 8046 replaced it in 2017 on the Standards Track, renamed the parameter, separated multihoming into RFC 8047 and added or clarified mobility cases. A standards inventory must record the implemented generation rather than treating every “HIP mobility” label as interchangeable.

Obsolescence is not proof that old code is running or broken. A citation to RFC 8046 is not proof of migration. Version, parameter parsing, state machine, retry policy, CBA settings and observed behavior require their own evidence.

The leadership decision

Approve separate service claims for authenticated mobility signaling, verified locator reachability, active protected path and application continuity. Require status pages and incident reports to name the layer they measured. Prohibit a green signature result from automatically satisfying the other three.

The minimum common protocol may authenticate the announcement and bound traffic during verification. Local policy still decides retry budgets, alternative-path preference, telemetry, retention and application failover. Running code supplies the route receipt. Governance prevents that narrow receipt from acquiring authority over facts it never observed.

Sources

  1. RFC 5206 information
  2. RFC 5206 HTML
  3. RFC 5206 text
  4. IETF Datatracker: RFC 5206
  5. RFC 5206 history
  6. RFC 5206 references
  7. RFC 5206 errata
  8. RFC 8046 information
  9. RFC 8046 HTML
  10. RFC 8046 text
  11. IETF Datatracker: RFC 8046
  12. RFC 8046 history
  13. RFC 8046 references
  14. RFC 8046 errata
  15. RFC 7401 — HIP Version 2
  16. RFC 7402 — HIP ESP transport
  17. RFC 8047 — HIP multihoming
  18. RFC 6973 — privacy considerations
  19. RFC 4423 — HIP architecture
  20. Heng Lu — reality layers and symbolic power
  21. Heng Lu — minimum initial specification
  22. Heng Lu — running-code primacy