Read the actual ROUTE-REFRESH message
03A Type 5 message carries a family, rather than another capability TLV.
Normal subtype-0 requests can be longer when ORF entries are present. The helper retains those extra octets without claiming to validate ORF; the plain 23-byte drawing is not a universal length for every Route Refresh extension.
Source for this drawing: RFC 2918 · 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.
The Reserved octet becomes Message Subtype under the enhanced procedures; Code 70 advertises enhanced support.
Read the updated RFC section ↗ROUTE-REFRESH is BGP Message Type 5. In the plain example without Outbound Route Filtering (ORF), its body is four octets: AFI (16 bits), Reserved (8 bits) and SAFI (8 bits). The common BGP header is 19 octets, so this chosen complete message is 23 octets (§3; RFC4271 §4.1).
- ROUTE-REFRESH is BGP Message Type 5. In the plain example without Outbound Route Filtering (ORF), its body is four octets: AFI (16 bits), Reserved (8 bits) and SAFI (8 bits). The common BGP header is 19 octets, so this chosen complete message is 23 octets (§3; RFC4271 §4.1).
- The common header has a 16-octet Marker set to all ones, a two-octet total Length and a one-octet Type. Our example is ff repeated 16 times, then 00 17 05, then 00 02 00 01. The 00 17 length includes the header; there is no outer OPEN optional-parameter wrapper here (RFC4271 §4.1; §3).
- The body’s AFI 2 and SAFI 1 identify IPv6 unicast. They are selectors for which advertisements to refresh, not an IP address, a route prefix or a Capability Code. Code 2 in an OPEN capability and Type 5 in a BGP message are distinct namespaces (§§2–3; RFC4760 §§6,8).
- The original RFC2918 Reserved byte should be zero on transmission and is ignored by a base-only receiver. RFC7313 §3.2 later redefines that byte as Message Subtype: 0 normal request, 1 beginning, 2 ending. Enhanced processing depends on receiving the enhanced capability; do not apply the old ignore rule indiscriminately to negotiated enhanced messages.
- The 23-octet example excludes ORF entries. RFC5291 §4 permits longer normal requests containing ORF data. The raw framing helper preserves trailing bytes but does not parse ORF. A longer subtype-0 body is not automatically the enhanced invalid-length error; the four-octet length requirement in RFC7313 §5 concerns subtypes 1 and 2.
Fictional documentation prefixes and selected route records illustrate control-plane behavior. No full BGP UPDATE codec, best-path algorithm, ORF, network session or security validation is implemented.
Read the RFC section ↗