Summary

  • draft-acee-lsr-ospfv3-deprecate-ah-00 proposes that new OSPFv3 implementations stop implementing IPsec Authentication Header and that operators move to ESP with NULL encryption or the OSPFv3 Authentication Trailer. Revision 00 is an individual work-in-progress draft, not an approved standard.
  • Deprecation is guidance, not migration. An OSPFv3 link uses one authentication mechanism and every router on it must agree; the replacement has to be accepted everywhere before transmit behavior changes, and the old path can be removed only after adjacency, database and forwarding receipts close the chain.

At 02:00, Router A begins sending OSPFv3 packets under the replacement mechanism. Router B has the new key but not the right inbound association. Router C supports the mechanism in its software image but has not enabled it on this interface. Router D still expects AH. Nothing in the word “deprecated” reconciles those four states. The first Hello packet does.

That is the operational importance of Deprecation of the IPsec Authentication Header (AH) for OSPFv3 Authentication, revision 00, dated 30 September 2026. The individual Internet-Draft has intended Standards Track status and says it would update RFC 4552 if approved. It is neither an RFC nor evidence that a working group, vendor or operator has already made the change.

The proposal is narrow. RFC 4552 requires ESP support and permits AH for OSPFv3. The draft would deprecate the AH path, tell new implementations that they should not implement it for this purpose, allow existing implementations to retain it for backward compatibility with a warning, and encourage operators to choose either ESP with NULL encryption or the OSPFv3 Authentication Trailer defined by RFC 7166.

Those alternatives protect integrity and authenticate possession of the relevant key material. ESP with NULL encryption does not add confidentiality. Neither mechanism can protect a link from a compromised router that already holds a valid shared key.

A standards state and a link state are different objects

The draft gives several reasons for consolidation. It says AH has seen very limited OSPFv3 adoption, is optional to implement under RFC 8221 and is no longer supported by many IPsec implementations. Maintaining distinct AH and ESP code, configuration and operating procedures adds complexity. On an ordinary OSPFv3 link, packets use link-local addresses and hop limit 1, limiting the incremental value of AH's coverage of immutable IPv6-header fields. RFC 7166's Authentication Trailer separately protects the IPv6 source address in its digest.

These are the authors' rationale, not a product census. More importantly, none of them is an on-wire negotiation. A draft can alter procurement and implementation priorities. It cannot tell an existing neighbor which Security Association to select, install a key, widen inbound acceptance or coordinate a cutover.

Revision 00 states the hard constraint directly: an OSPFv3 interface or virtual link is configured with a single authentication mechanism, and all routers on the link must agree. The safe unit of change is therefore the link, not the router ticket.

A unilateral change is not gradual adoption. It is a new packet-validation rule presented to neighbors that may be unable to satisfy it. A mismatch in Authentication Trailer SA ID, authentication type or digest prevents adjacency formation. Comparable mismatches in the IPsec policy and association set drop the packets before OSPFv3 can treat them as a healthy exchange.

Prepare acceptance before changing transmission

RFC 4552 already contains a useful three-stage discipline for rekeying without breaking OSPFv3. First, create a new inbound Security Association on every router. Second, only after every router can receive the new state, replace the outbound SA. Third, remove the old inbound SA only after every router transmits with the new one.

An AH-to-ESP migration is not merely a key rollover, but the ordering principle survives: receive new, send new, retire old. The evidence has to be link-wide at each boundary.

The new draft offers two operating shapes. One is a coordinated maintenance window in which the replacement mechanism and keys are prepared on every router. The other is a staged approach on implementations able to accept more than one mechanism during a transition. That capability must be demonstrated; it cannot be inferred from a product family or from outbound support.

Overlap has a cost. Too little acceptance overlap divides the adjacency graph. Too much leaves an older or weaker acceptance path open beyond its purpose. The window needs an owner, start and end times, an exact link membership list and a condition that stops the cutover when any router lacks the expected receipt.

Manual keying remains the only method RFC 4552 specifies for OSPFv3 use of IPsec. Its rekey procedure requires all routers to finish adding the new inbound SA before any begins using the new outbound SA, then all to finish the outbound switch before old inbound state is removed. The interval is chosen by the operator because deployment scale and implementation behavior vary.

The alternative is not one uniform fallback

ESP with NULL encryption and Authentication Trailer lead to different operational surfaces. ESP-NULL stays inside the IPsec architecture and RFC 4552's SA and manual-key profile. Authentication Trailer is carried with OSPFv3, has an SA identifier and a 64-bit increasing cryptographic sequence number, and protects the IPv6 source address as part of its digest construction.

RFC 7166 also defines an optional compatibility transition mode. A router can send Authentication Trailer while still accepting packets without it. That can keep older neighbors reachable, but the RFC explicitly warns that such a deployment may be exposed to unauthenticated data during the transition.

This is not a reason to reject transition. It is a reason to name the trade. Continuity is being purchased by temporarily widening acceptance. A dashboard that reports only “adjacency Full” hides whether the packet was authenticated under the new mechanism, accepted under an old one or accepted without Authentication Trailer under compatibility rules.

The same separation applies to identity. A valid digest shows that a sender had access to the shared key. It does not identify a particular human operator, prove that the specific router is uncompromised, or authorize every LSA it emits.

Adjacency is a checkpoint, not the outcome

A defensible migration produces a chain of receipts:

  1. the exact draft and chosen replacement are recorded;
  2. every attached router's running build demonstrably supports that replacement;
  3. inbound SA or Authentication Trailer state, algorithm and key epoch are installed everywhere;
  4. outbound selection changes only after the acceptance set is complete;
  5. authenticated Hello and Database Description packets are observed under the intended mechanism;
  6. every required neighbor returns to and holds Full state;
  7. link-state databases converge to the expected inventory;
  8. recalculated routes, programmed forwarding and bounded traffic checks succeed;
  9. old AH or permissive transition acceptance is removed and the checks repeat.

No row proves the next. A Full adjacency can coexist with the wrong acceptance path. A converged database does not prove the FIB. Successful traffic before old acceptance is removed does not prove the replacement carried it.

The final removal is part of the migration, not cleanup. Until the old path is gone—or deliberately retained with an expiry and owner—the network has not reached the declared compatibility set.

Publication can guide adoption; running code proves it

Heng Lu's distinction among minimum common specification, localized future decision and voluntary adoption is useful here. The shared layer should define only what peers need to interoperate: packet construction, acceptable algorithms, key and sequence behavior, and the conditions under which an adjacency is valid. Operators retain the decision about replacement mechanism, maintenance scope and transition duration.

Voluntary adoption does not mean each router can change at an arbitrary moment without consequence. On a shared link, one participant's outbound choice becomes every neighbor's inbound requirement. Local choice remains real, but incompatibility must be visible rather than disguised as a completed migration.

The leadership question is therefore not whether AH has been marked deprecated. It is whether every router on the link can show the same new packet, the same key epoch and the same acceptance result—and whether the old path has actually closed.

Sources