Summary

  • RFC 5492 lets BGP peers list optional capabilities in OPEN. An extension may be used only when both peers advertised it; an unknown received capability must be ignored, while a capability required for the intended peering may be named in an explicit failure.
  • John Scudder's attributed record continues from the small code-length-value declaration to RFC 8810's repair of a confusing private code space and RFC 9072's enlargement of the 255-octet OPEN option envelope. Together they show that extensibility needs mutual evidence, a shared registry, and an honest stopping point.

The connection was up; the agreement was not

A BGP session begins before any route is exchanged. The speakers create a TCP connection and send OPEN messages describing the parameters under which they propose to talk. That moment can look procedural, but it carries a difficult distributed-systems question: how can one implementation introduce a new protocol feature without assuming that every neighbor was upgraded at the same time?

The base behavior described in RFC 5492 made an unknown OPEN Optional Parameter fatal to the peering. That was clear but expensive. A new extension placed in an unfamiliar parameter could close a relationship that might otherwise have exchanged ordinary routes safely. Avoiding the problem by never extending OPEN would preserve the old session at the price of freezing BGP's vocabulary.

Capability Advertisement creates a narrower choice. A speaker can place a Capabilities Optional Parameter in OPEN and list the extensions it supports. The peer can understand the container even when it does not understand every capability inside it. The session is no longer forced to treat every new idea as a new kind of OPEN message.

John Scudder and Ravi Chandra are the named authors of RFC 5492, published in February 2009 and replacing an earlier version of the mechanism. Scudder is the author of RFC 8810, the 2020 revision of Capability Code registration, and shares authorship of RFC 9072, the 2021 OPEN-length extension, with Enke Chen. The IETF Datatracker profile connects those documents to a broader public routing record.

That is enough for a person-centred analysis and not enough for a hero story. Each RFC is an IETF consensus document shaped by co-authors, working-group review, implementers, operators, IANA, and later experience. The byline establishes documented participation. It does not give one person ownership of BGP, a vendor's parser, an operator's configuration, or the outcome of a live session.

A declaration is small enough to inspect

The capability record has three parts. A one-octet Capability Code identifies the capability. A one-octet Capability Length says how many octets follow. The variable Capability Value carries whatever data the specification for that code defines.

This is a deliberately thin common language. The container does not try to describe every extension centrally. It says how a capability is named and bounded; the document that creates the capability must define what its value means, including how multiple instances are processed when that is allowed. Independent implementations can parse the envelope without one giant authority rewriting the entire protocol for each feature.

The syntax also exposes identity and content as separate facts. A codepoint says which specification should interpret the value. It does not say that the value is well chosen, that the implementation follows the specification, or that the operator intended to enable the feature on this neighbor. A correct length prevents one field from consuming the next; it does not make the message trustworthy.

RFC 5492 recommends one Capabilities Optional Parameter containing the collection of capability TLVs. For backward compatibility, however, a receiver must accept several Capabilities Optional Parameters and process the combined set in the same way. Identical duplicates add no meaning, yet receivers must tolerate them. Different values under one code require capability-specific rules.

These details resist a fragile implementation assumption. A parser cannot treat one convenient encoding produced by its own software as the only valid representation. The public contract is the accepted set and its semantics, not the exact layout one product happened to emit.

Both peers must put the capability on the record

The core rule is bilateral: a capability can be used on a peering only after both speakers advertised it. If either side did not advertise, the capability cannot be used for that session.

This is stronger than detecting whether the remote binary probably contains some feature. An operator may disable a supported feature. A software release may implement it only for certain address families. Neighbor-specific configuration may omit it on one relationship. The evidence that matters at the session boundary is what each speaker declared to that peer in that OPEN exchange.

The rule also limits unilateral power. A speaker cannot make an optional extension active merely by sending an advertisement and assuming silence means consent. Nor can a central registry enable the feature by assigning its code. IANA can keep the name unique; the capability specification can define behavior; the implementation can offer support; the operator can configure it. Use on the session still depends on the record from both ends.

Mutual advertisement is not necessarily symmetric behavior. A capability specification may define direction, value, or role-specific semantics. The shared rule establishes the prerequisite, not every resulting action. Monitoring that shows only “capability present” can therefore be incomplete. It should retain what each side sent, which values were attached, and what the specific extension says those values permit.

Unknown is not the same as required

RFC 5492 draws a line that is easy to reverse in implementation or operations. If a speaker receives a capability it does not support or recognize, it must ignore that capability. It must not send Unsupported Capability and must not terminate merely because the peer announced something new.

This is the extensibility bargain. Novel information remains inert for a speaker that cannot interpret it, while the rest of the session may continue. The old implementation does not gain a fake understanding; the new implementation does not gain a veto over the entire relationship merely by advertising an option.

The inverse case concerns local requirements. Suppose a speaker was configured to establish the peering for a function that depends on a capability—RFC 5492 uses IPv6 exchange as an example—and discovers that the peer did not advertise it. The speaker may send an Unsupported Capability NOTIFICATION and terminate. The notification must contain the capability or capabilities whose absence caused the decision. Whether the feature is required is a local choice.

If the peering ends for that reason, the RFC says it should not be re-established automatically. An automatic loop would repeatedly create TCP, exchange the same evidence, reach the same incompatibility, and erase the distinction between recovery and repetition. A human or automation system needs to change the configuration, software, intended service, or peer expectation before another attempt becomes meaningful.

Unknown received capability and missing required capability therefore answer different questions. The first asks whether novelty outside the local feature set must kill ordinary interoperability; the answer is no. The second asks whether this particular intended relationship can meet its declared purpose; the answer may also be no. A reliable implementation preserves both answers instead of collapsing them into a generic “capability mismatch.”

Legacy fallback preserves a session, not its purpose

There is an older boundary beneath individual capabilities. A peer may reject the entire Capabilities Optional Parameter with Unsupported Optional Parameter. In that case RFC 5492 says the supporting speaker should try to reconnect without sending the capability container.

That behavior provides a bridge to older BGP speakers. It can restore a base session that has no way to express the newer optional feature set. But restoration is not success by definition. If the intended service depends on multiprotocol reachability or another capability, a capability-free session may be operationally useless or unsafe to treat as complete.

The fallback must therefore be observed as a different state, not a silent retry. The operator should know that the first OPEN was rejected, that a second attempt omitted the capability container, and which intended functions became unavailable. A green TCP or Established indicator cannot answer whether the session still performs the work for which it was commissioned.

The distinction protects backwards compatibility from becoming lowest-common-denominator governance. Supporting old peers is valuable where the base function remains sufficient. It does not require every new service to pretend an absent prerequisite is acceptable.

A private code was not private once products met

Capability Advertisement depends on numbers having shared meaning. RFC 5492 originally placed codes 128 through 255 in a Private Use range. RFC 8810 records the later conclusion in unusually direct terms: experience made the range not only unhelpful but confusing to implementers.

The problem follows from interconnection. Two products can privately choose the same number for different features and behave correctly inside separate laboratories. When the products meet, the number no longer carries a private label. Each side can parse the same code and attach a different meaning to it. A field designed to reveal compatibility becomes a collision surface.

RFC 8810 restructures the space. Codes 1–63 remain under IETF Review. Codes 64–238 use First Come First Served registration. Codes 239–254 are for Experimental Use. Code 255 is Reserved. The Experimental range is meant for early development, not long-term use or shipping products.

This is registry governance at its thinnest. The registry prevents accidental semantic reuse and gives a reader a reference. It does not evaluate whether a capability should be enabled on a network, whether the business case is sound, or whether an implementation is reliable. Its authority ends at the common name and allocation procedure.

The repair also preserves uncertainty. Before changing the former Private Use range, the work surveyed known uses and seeded the registry with several pre-standard assignments. RFC 8810 does not claim every private use was discovered. Residual collisions remain possible and must be handled as collisions, not erased by institutional confidence.

Even the negotiation envelope had a finite edge

The OPEN message's Optional Parameters Length was originally one octet. That capped the complete options area at 255 octets. Each capability was small, but the number and richness of capabilities continued to grow. The mechanism that allowed BGP to evolve was approaching a limit in the place where evolution had to declare itself.

RFC 9072 extends the envelope without making every small OPEN use a new encoding. At or below 255 octets, the base form should normally remain. If the total exceeds 255, a distinguished type value of 255 signals an extended layout with a two-octet total length; individual Optional Parameter lengths also become two octets. A receiver that implements the RFC must accept the extended form even when a sender uses it for a smaller set.

The compatibility rule is precise rather than magical. A new speaker and an old speaker can interoperate while the new speaker's options fit the old envelope. Once the new speaker actually needs more than 255 octets, it must send the extended form. The old speaker sees an optional-parameter type it does not understand and is expected to close the connection with Unsupported Optional Parameters.

That failure is useful evidence. It shows exactly where compatibility ended: not at software age in the abstract, but at a message the old parser could no longer decode. Allowing the peer to continue while silently dropping bytes would produce a more dangerous ambiguity. Backward compatibility preserves the common subset; it does not grant an old implementation imaginary capacity.

RFC 9072 also leaves the base BGP security and confidentiality issues unchanged. A larger field can carry more declared features, but it does not authenticate the declaration or make the session private.

Minimum shared rules, local decisions, running proof

Lu Heng's later essay on Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption provides Sofia Ren with a useful lens for this record. The shared layer is small: an interpretable container, unique codepoints, a mutual-use rule, bounded failure messages, and an extensible length. Each capability's detailed meaning and each operator's decision to require it stay closer to those who implement and bear the consequence.

The resemblance should not be inflated into a claim about the authors' private philosophy. Heng's framework is a 2026 editorial interpretation. RFC 5492, RFC 8810, and RFC 9072 stand on their own normative text and collective IETF history.

Running-Code Primacy supplies the verification test. The OPEN exchange is stronger evidence than a product brochure because it records what the two running speakers actually declared to each other. It is still only one layer. Operators must verify the resulting negotiated state, accepted messages, route exchange, error path, forwarding behavior, and recovery.

A capability record is neither a command nor a warranty. Its achievement is more modest and more durable: two independent systems can state what they know, refuse what they require, ignore what they do not understand, and keep the boundary visible. The BGP session does not need a sovereign to decide every extension. It needs both peers to tell the truth in a language the other can parse—and operators willing to test whether the running system lives up to that declaration.

Sources