Handle a missing required feature deliberately
05A local requirement can justify termination; an unknown received capability cannot justify that error.
Separate registry lookup: RFC8810 replaces the old blanket Private Use range. A Capability Code’s allocation policy does not prove that a peer supports it, that values are compatible, or that the peer is authenticated.
Source for this drawing: RFC 5492 · Read RFC section 5 ↗
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.
The former Private Use range 128–255 became First Come First Served 128–238, Experimental Use 239–254, and Reserved 255. The combined First Come First Served range is now 64–238.
Read the updated RFC section ↗A speaker may need a particular extension to carry out its intended peering. In our separate chosen case, A advertises and locally requires the Multiprotocol IPv6-unicast tuple, but B advertises only Route Refresh. The required tuple is missing; that is not the same as receiving an unfamiliar capability (§3).
- A speaker may need a particular extension to carry out its intended peering. In our separate chosen case, A advertises and locally requires the Multiprotocol IPv6-unicast tuple, but B advertises only Route Refresh. The required tuple is missing; that is not the same as receiving an unfamiliar capability (§3).
- On determining that the peer lacks a supported capability, the speaker MAY send a NOTIFICATION and terminate peering. This is a local decision, not a MUST to close every session with different feature sets. If chosen, the Error Code is 2 and Unsupported Capability Subcode is 7 (§§3,5; RFC4271 §4.5).
- The NOTIFICATION Data MUST list the capability or capabilities causing that decision, encoded as Capability Code/Length/Value TLVs. Our missing IPv6-unicast tuple produces the isolated body 02 07 01 04 00 02 00 01. It is not an outer Capabilities parameter, and the full BGP header is not shown (§5).
- If peering is terminated for this missing-feature reason, it SHOULD NOT be re-established automatically. Do not substitute the legacy retry-without-capabilities branch or turn SHOULD NOT into an absolute ban on all later operator decisions (§3).
- RFC8810 updates RFC5492’s registration policy: 0 and 255 Reserved; 1–63 IETF Review; 64–238 First Come First Served; 239–254 Experimental Use. The old blanket 128–255 Private Use allocation is no longer the rule. A registry policy or advertised feature is not authenticated identity or authorization; this extension does not change underlying BGP security (§§6–7; RFC8810 §§1–4).
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 ↗