RFC 3392: Capabilities Advertisement with BGP-4
This RFC has been replaced. Do not implement against it for new work — it was formally obsoleted by RFC 5492.
Current document in this lineage: RFC 5492 — Capabilities Advertisement with BGP-4
In plain English — editorial summary, not part of the RFC
Currently BGP-4 requires that when a BGP speaker receives an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP. This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC2842.
Document record
- Document ID
- RFC3392
- Published
- November 2002
- Authors
- R. Chandra; J. Scudder
- Status
- DRAFT STANDARD
- Stream
- IETF
- Area
- rtg
- Pages
- 6
- Also known as
- —
Topics
Standards lineage
This document is one revision in a chain of 3 RFCs, each formally replacing the one before it.
- RFC 2842 (2000)
- RFC 3392 (2002)
- RFC 5492 (2009) ✓
Read the full history of Capabilities Advertisement with BGP-4 →
Referenced by
One later RFC formally updates or obsoletes part of this document.
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 3562Key Management Considerations for the TCP MD5 Signature OptionCurrent
July 2003
- RFC 3107Carrying Label Information in BGP-4Obsoleted
May 2001
- RFC 2918Route Refresh Capability for BGP-4Updated
September 2000
- RFC 2796BGP Route Reflection - An Alternative to Full Mesh IBGPObsoleted
April 2000
- RFC 2439BGP Route Flap DampingCurrent
November 1998
- RFC 2385Protection of BGP Sessions via the TCP MD5 Signature OptionObsoleted
August 1998
- RFC 3219Telephony Routing over IP (TRIP)Updated
January 2002
- RFC 4808Key Change Strategies for TCP-MD5Current
March 2007
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?