Advertise features before using them
01Two OPEN messages communicate support; an advertisement is not a request, acknowledgement or completed session.
Both now advertise the IPv6-unicast tuple, satisfying the shown mutual-advertisement condition. This makes that feature eligible under its specification; the remaining BGP session checks are not simulated.
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.
BGP means Border Gateway Protocol. A BGP speaker is a router process exchanging routing information with a peer. OPEN is its opening BGP message after TCP connection setup. A capability is an optional protocol extension. A supporting speaker MAY include the Capabilities Optional Parameter in OPEN (§3; RFC4271 §4.2).
- BGP means Border Gateway Protocol. A BGP speaker is a router process exchanging routing information with a peer. OPEN is its opening BGP message after TCP connection setup. A capability is an optional protocol extension. A supporting speaker MAY include the Capabilities Optional Parameter in OPEN (§3; RFC4271 §4.2).
- A speaker learns its peer’s advertised capabilities from the received OPEN. RFC5492 describes using a capability on a peering after both peers have advertised it. Each extension’s own rules still matter; a shared code is not a substitute for checking its parameters (§3).
- Our principal example is Multiprotocol IPv6 unicast: both peers advertise the same Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI). RFC4760 §8 requires each to advertise that particular tuple for bidirectional exchange. The chosen tuple is AFI 2 / SAFI 1; these mean IPv6 / unicast.
- An advertised feature is not an acknowledgement of the other peer’s list, a command to activate every extension, or proof of authenticated identity. Other OPEN checks, KEEPALIVEs and the BGP state machine still apply; capability eligibility alone is not an established session (RFC4271 §4.2; §7).
- Route Refresh is another concrete capability used in our wire examples. It advertises the ability to receive and handle ROUTE-REFRESH messages (RFC2918 §2). The helper compares shared advertisements; it does not implement that extension’s directional operation or actual routing updates.
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 ↗