Visual RFC.
ALL RFCs / RFC 5492
Read the RFC ↗

RFC 5492 / START HERE

BGP capability advertisement, before the details

BGP capability advertisement

BGP means Border Gateway Protocol. A capability is an optional feature that BGP peers can advertise while opening their connection. The advertisements tell each side which extensions the other says it supports.

Start the guide See the 5 chapters ↓

The idea in one picture

  1. Advertise local support

  2. Compare feature values

  3. Choose the right outcome

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

Base BGP closes peering for an unrecognized OPEN Optional Parameter. RFC5492 puts extensible feature records inside a recognized parameter, allowing unfamiliar capabilities to be ignored. This February 2009 Draft Standard replaces RFC3392; RFC8810 later updates its code-registration policy.

A familiar example

Think of two interpreters each listing the languages they can use. A language appearing on both lists is a candidate for their conversation; the list itself is not a request, an acknowledgement or proof of identity. The chapters use IPv6 routing support and actual capability bytes, with separate legacy and required-feature failures.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

BGPRFC 4271 · beginner overview ↗TCPRFC 9293 · beginner overview ↗Route reflectionRFC 4456 · beginner overview ↗

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Advertise features before using themTwo OPEN messages communicate support; an advertisement is not a request, acknowledgement or completed session.
  2. Read the nested capability bytesA capability has Code, Length and Value inside a separate OPEN Optional Parameter.
  3. Accept equivalent lists and repeated recordsPreferred transmission and mandatory receive compatibility are different rules.
  4. Separate unknown capabilities from legacy errorsIgnoring an unfamiliar inner TLV is different from a peer rejecting the outer parameter.
  5. Handle a missing required feature deliberatelyA local requirement can justify termination; an unknown received capability cannot justify that error.
Start with chapter one →

This introduction explains RFC 5492 (2009). Read the original RFC ↗