Separate unknown capabilities from legacy errors
04Ignoring an unfamiliar inner TLV is different from a peer rejecting the outer parameter.
The 2/4 case recommends retry without capabilities. The 2/7 case concerns a locally required feature and is not this legacy fallback. The same Error Code 2 does not make the subcodes interchangeable.
Source for this drawing: RFC 5492 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A capability-aware speaker that receives a capability it does not support or recognize MUST ignore that capability. It MUST NOT generate Unsupported Capability or terminate the session in response to that received unsupported capability (§3). Other independent errors or requirements can still prevent peering.
- A capability-aware speaker that receives a capability it does not support or recognize MUST ignore that capability. It MUST NOT generate Unsupported Capability or terminate the session in response to that received unsupported capability (§3). Other independent errors or requirements can still prevent peering.
- Our unknown example is a well-framed Capability Code 239 with two opaque Value bytes. The selected teaching implementation does not recognize it. Its experimental registration range does not give it an invented interoperable meaning or make it trusted (§3; RFC8810).
- In a separate legacy case, an OPEN carrying the Capabilities Optional Parameter receives NOTIFICATION Error Code 2 (OPEN Message Error), Subcode 4 (Unsupported Optional Parameter). RFC5492 describes this as detecting a peer that does not support capabilities advertisement (§3; RFC4271 §§4.5,6.2).
- In that legacy case the speaker SHOULD attempt to re-establish a connection without sending the Capabilities Optional Parameter. This is a recommended new connection attempt, not an acknowledgement, a mandatory endless retry loop or a command to remove all other optional parameters. Other BGP and local policy checks still apply (§3).
- Unsupported Capability is Subcode 7, for the different missing-required-feature case in the next chapter. Do not infer legacy fallback merely from an absent optional advertisement, an unfamiliar inner Capability Code, any arbitrary error, or Subcode 7. Rejected erratum 3882 is not applied: the published SHOULD remains a recommendation.
Worked examples use selected capability formats and classic OPEN optional-parameter framing. This is not a full BGP parser, state machine, routing implementation or authentication check.
Read the RFC section ↗