Summary

  • RFC 8206 requires a locally configured BGPsec PE to retain valid keys for both ASNs, including the old key until its relevant eBGP sessions have migrated; that is a conditional path-authentication mechanism, not a corporate record.
  • A concurrent ROA, a dual signature or a pCount=0 transition segment can support a narrow routing conclusion only in its defined trust boundary. None proves a merger, an acquisition, a completed migration, peer consent, delivered traffic or service success.

An old number has a powerful rhetorical pull. It suggests history, while a new number suggests succession. If both can sign the same route, the temptation is to narrate a completed business story: two systems became one, the old identity survived only as paperwork, and the technical trace tells outsiders who now controls what. That story is much larger than the evidence in a BGPsec update.

Wesley George and Sandy Murphy wrote RFC 8206 to solve a more prosaic problem. The document considers an Autonomous System migration in which a provider may merge ASes, retain legacy identifiers for a period, or make a provider-edge router appear to a peer as the old ASN. The conditional language matters. A provider may merge ASes; the RFC does not identify one that did. It describes a protocol constraint that can arise during migration, not a registry of corporate acts.

The starting condition is deliberately untidy. Migration can take a long time. The RFC does not make every BGP speaker change at once, and it does not demand coordination with every customer. Older ASNs can remain in use while the operator shifts local sessions and configuration. That is why an old key has to be understood as an operational dependency. A key can remain valid because a PE still has an adjacency whose configured expectations have not moved. It is neither a press release nor a notarized statement about the organization behind the ASNs.

Origin validation makes the distinction sharper. During a transition, the replacement ASN can need a ROA for a prefix even while PEs using the old ASN also originate it. RFC 8206 permits concurrent origin authorizations. But a ROA says something bounded: a holder of the relevant RPKI authority has authorized an ASN to originate a prefix for origin-validation purposes. It does not settle a company's ownership, a merger agreement, the state of every router, the preference selected by a remote network, or the result of a user transaction. Two ROAs expand a permitted origin set; they do not turn that set into a completion certificate.

BGPsec path validation is a different layer again. RFC 8205 describes the cryptographic model: RPKI certificates attest allocations of AS numbers and IP address space; a signer uses a corresponding private key, while a receiver validates a path without possessing that key. A valid signature therefore answers a limited question about the constructed BGPsec path. It does not answer who negotiated a commercial transaction, whether a change window was completed, or whether traffic reached its destination.

RFC 8206 narrows the path question still further. Its procedure lives at a PE that is locally configured with the relevant old and new ASNs and faces an existing eBGP peer. In the outbound case, the PE signs with both configured ASNs. The transition signature for the old ASN has pCount=0. When an ordinary non-BGPsec peer needs a reconstructed AS_PATH, that hidden transition segment is not presented in the reconstructed path; it remains in the BGPsec Secure_Path. In the inbound case, a PE facing a CE that still expects the old ASN adds the defined pCount=0 segment under its local condition.

This is not a technique for carrying a corporate assertion across the Internet. The RFC rejects the idea that an untrusted customer domain can simply be expected to accept a pCount=0 segment. The procedure is constrained by an existing trust boundary, local policy and a known adjacency. It does not demand a remote CE reconfiguration, a globally synchronized configuration, or a longer visible AS_PATH. Precisely because it avoids those broad demands, it cannot demonstrate that they were met elsewhere.

The key-retention rule is equally conditional. The PE needs valid keys for both ASNs and must retain the old key until all of its relevant eBGP sessions have migrated. “Until all sessions have migrated” is a maintenance obligation placed on the PE operator, not a fact emitted by a single signature. A path validator then judges the received path according to its own configured trust and business relationship. One validator's acceptance is evidence about its policy and that signed path at that time; it is not a census of migration progress in every peering relationship.

This gives a useful evidence ladder. A public RFC supplies the procedure. An RPKI object supplies a scoped authorization. A key state permits a cryptographic act. A BGPsec update records a signed path. A validator result records a policy decision. Session telemetry can show a particular adjacency changed. Packet and forwarding records can show what traffic did. Legal instruments, registry records and corporate disclosures are separate records for institutional facts. Skipping from the third or fourth rung to a claim about a merger is not inference; it is substitution.

Heng Lu's minimum-initial-specification principle describes why the RFC should be read with this restraint. A common protocol layer should settle the deterministic minimum needed for interoperable and secure behavior. It should not annex future choices that remain local: when to change a configuration, which peers to migrate, who holds a key, whether a customer accepts the plan, or whether a business transaction is true. Voluntary adoption becomes operationally real only where compatible actors implement, validate and accept it.

RFC 8206 offers the thin shared rule; it does not convert the local migration around it into a global declaration.

An operator investigating a real transition therefore needs a chain rather than a dramatic artifact. Preserve the PE configuration scope, relevant session inventory, old and new key validity windows, ROA state, exact BGPsec path, validator policy and result, the time each adjacency moved, and independent packet or service measurements. If the question is corporate control, obtain the appropriate corporate and registry records separately. The old key is meaningful. It is simply meaningful at the key-and-path layer where the RFC put it.

Sources