Summary

  • RFC 5203 gives different protocol roles to service advertisement, registration request, authorization, failure and cancellation; a successful REG_RESPONSE proves a completed registration for named types and a lifetime, not later service execution.
  • Registration is finite soft state. The registrar or attached service can cancel before expiry, and service-specific dependencies sit outside the generic extension.
  • A trustworthy operational verdict joins registrar and requester state with attached-service acknowledgement, current availability, the attempted service transaction and its observed result.

A green timer with nothing behind it

Imagine a branch host receiving a signed REG_RESPONSE for a traversal service. The granted lifetime is 120 seconds. A controller records the answer and displays a green badge until the calculated expiry.

Thirty seconds later, a configuration reload removes the state in the attached service. The registrar remains reachable. It attempts to cancel the registration with a zero-lifetime response, but the update follows a stale path and never reaches the requester. The next service-specific packet is refused. The badge stays green because its clock is still running.

This is a constructed scenario, not a report of an implementation or outage. Its value is that every component can behave within a plausible local boundary while the aggregate verdict is false. The original response really did grant registration. The local lifetime really has not expired. Neither fact says that the service-side state still exists, that a cancellation arrived, or that a later operation succeeded.

RFC 5203 makes the distinction available to anyone willing to keep its messages separate. Operational software loses it when it turns a sequence of state transitions into a single Boolean called available.

The extension deliberately stops at the service boundary

The 2008 Experimental RFC defines a generic way for a HIP host to register with services such as a rendezvous server or middlebox. It does not define how the host discovers a service or locates a registrar. It also does not define how the host interacts with the service after registration. Other specifications own those operations.

That scope is not an omission to be silently filled by an optimistic dashboard. It is the protocol boundary. The generic layer can say that a registration request was received, a requester was authenticated, local authorization policy was applied and a registration type was granted for a lifetime. It cannot manufacture a service-specific receipt that the generic exchange never carried.

RFC 5203 defines registration as shared state stored by requester and registrar that allows the requester to benefit from one or more services. The verb “allows” is important. It creates a permitted, time-bounded relationship. It is not a retrospective claim that a benefit was used or delivered.

The RFC later says successful processing of REG_REQUEST creates state at the registrar and possibly at the service. That one qualifier prevents a large category error. Registrar state and service state may be related, but the specification does not make them indistinguishable. An inventory that stores only registered=true discards which component actually created what.

Advertisement, request and grant are three different moments

The registrar first describes what it can offer with REG_INFO. A capable and willing registrar should include that parameter in its R1 packets. If transient conditions make service unavailable, it should send an empty REG_INFO. When its offering changes, it should update associated hosts with the current set.

The requester then asks for named types with REG_REQUEST. It is not supposed to request a type unless the most recent relevant advertisement included it. The request carries a preferred lifetime. It is an expression of desired state, not authority to create that state.

The registrar authenticates the requester from the Host Identity and applies local authorization policy. REG_RESPONSE lists the types it authorized and the lifetime it granted. REG_FAILED carries types that were refused or failed. In RFC 5203, failure zero calls for additional credentials and failure one says the type is unavailable.

These messages answer adjacent but nonidentical questions:

  • REG_INFO: what the registrar said it could presently offer;
  • REG_REQUEST: what this requester asked to register;
  • REG_RESPONSE: what registration the registrar authorized and completed;
  • REG_FAILED: what was not completed and the available reason class.

None says that an application later invoked the service. None contains a packet-delivery receipt from the attached function. None guarantees that availability observed at advertisement time persisted until use.

A granted lifetime is not an uptime promise

RFC 5203 encodes requested and granted lifetimes compactly. A requester cannot assume it will receive the value it asked for, even when the request lies inside the advertised minimum and maximum. The registrar chooses the returned lifetime.

That field is useful. It tells both sides how long the registration state is meant to remain valid absent another transition. But it is soft state, not a service-level agreement. Zero lifetime cancels it. A requester may cancel early. A registrar or attached service may cancel early when the capability is no longer needed or can no longer be provided. The security discussion also permits a registrar to cancel at its discretion under resource pressure or attack.

Expiry and cancellation are separate causes. Service loss is yet another. A monitoring model needs at least four timestamps: state creation, last refresh, cancellation observation and expected expiry. If the attached service has its own state, that state needs its own identifier and clock.

The absence of a cancellation packet does not invert into proof of continuity. The registrar is told that it should send a zero-lifetime response, but the requester may not receive it. A path can fail. An update can be filtered. An implementation can crash. Observation can be incomplete. “No cancellation observed” is an evidence gap, not an affirmative health check.

Authentication can be strong while inference is weak

It would be wrong to dismiss REG_RESPONSE as a weak or informal message. HIP protects the response, and the registrar has authenticated the requester and applied policy. The response is valuable evidence for exactly the decision it records.

The error arrives later, when the evidence is promoted. A signature can protect the integrity and origin of a statement. It does not enlarge the statement's subject. An authenticated registrar can truthfully say that it granted registration type S for lifetime L. The same signature does not cause an attached middlebox to retain state, make a service path reachable, or prove that a future packet was accepted.

This is a recurring infrastructure mistake: cryptographic confidence is mistaken for semantic breadth. The stronger the signature, the more tempting it becomes to reuse the result as a universal health token. Good evidence architecture does the opposite. It preserves the signed object and attaches a precise scope: principal, registration types, lifetime, protocol epoch and decision.

RFC 8003 changed the protocol, not this boundary

RFC 8003 obsoleted RFC 5203 in 2016 and moved the registration extension onto the Standards Track. It clarified willingness with respect to a particular requester, expanded certificate-based authorization handling and added an insufficient-resources failure type. It retained the structure that matters here: availability advertisement, request, response, failure, finite lifetime and cancellation.

The update improves the vocabulary for refusal. An operator can distinguish unavailable type, missing credentials, invalid certificate and insufficient resources more precisely. Better failure codes reduce ambiguity at the decision point. They do not create evidence about later service execution.

Nor does the existence of the successor prove migration. A product document can cite RFC 8003 while a deployed build implements an earlier profile, disables a type, omits a cancellation path or delegates service state to another component. Version, build, configuration and observed message all belong in the receipt.

RFC lineage is evidence about specifications. Running-code evidence is about the actual system. Both matter; neither can stand in for the other.

The service-specific specification owns the next proof

RFC 5203 expressly allows a registration type to depend on additional HIP parameters not carried in the generic request or response. Their semantics belong to the registration-type specification. This is how a narrow common mechanism should behave: it standardizes registration without pretending that every service has the same execution contract.

For a rendezvous service, useful proof may include an accepted registration, a stored HIT-to-locator binding, a later I1 received by the server, a forwarding action and the responder's independent reply. For a middlebox service, it may include an installed rule, exact match, lifetime, policy owner and packets observed through the rule. The generic grant is one prerequisite in each chain, not the last rung.

Combining the chains in one database is reasonable. Flattening them into one status is not. A joined view should expose component states rather than overwrite them:

advertised → requested → authorized → registrar-state → service-state → used → outcome.

Each arrow requires evidence. If the service exposes no acknowledgement, the honest field is service_state=unknown. Unknown is not an operational embarrassment. It is the point at which measurement must begin.

A receipt that survives the green badge

A compact record can preserve the whole authority chain without capturing every packet forever:

  • HIP and registration-extension version, implementation build and configuration revision;
  • requester and registrar HITs;
  • signed REG_INFO fingerprint, advertised types and lifetime range;
  • REG_REQUEST fingerprint, requested types and lifetime;
  • authenticated requester, credential result, policy revision and decision owner;
  • REG_RESPONSE or REG_FAILED fingerprint, per-type result and granted lifetime;
  • requester-side and registrar-side state identifiers, creation, refresh and expiry;
  • attached-service acknowledgement and state identifier;
  • cancellation, eviction, configuration change and resource-pressure events;
  • service-specific request, response and observation points;
  • final operational outcome and unresolved gaps.

The receipt follows the claim instead of the user interface. It lets an auditor ask whether the dashboard was green because a current service transaction succeeded or merely because an old registration had not reached its calculated expiry.

It also gives automation a safer contract. A controller may reuse the registration decision while its lifetime and configuration epoch remain valid. It must reacquire attached-service evidence after a restart or reload. It must not suppress a fresh probe merely because the registration timer still has seconds left.

The authority of a registrar is real and limited

The registrar is the correct authority for whether it granted registration under its policy. The requester is the authority for whether it processed that grant. The attached service is the authority for whether it created and retained service state. The network path can show whether later traffic arrived. The application can show whether useful work occurred.

This division is not bureaucratic. It is what prevents a component from being blamed for a claim it never made. When the service fails while the registrar remains healthy, the evidence points to the missing rung. When a cancellation is sent but not received, the two state histories show the divergence. When an application fails after successful service use, the registration layer is not made to confess to an application outcome outside its sight.

The lesson of RFC 5203 is therefore not that registration is unreliable. It is that registration is precise. Its precision is lost only when a system asks the response to speak for availability, execution and outcome. Keep the state transitions separate, and a valid “yes” remains useful without becoming a false promise.

Sources