Network Working Group R. Chandra
Request for Comments: 2842 Redback Networks Inc.
Category: Standards Track J. Scudder
cisco Systems
May 2000
Capabilities Advertisement with BGP-4
1. Overview of Operations
When a BGP speaker that supports capabilities advertisement sends an OPEN message to its BGP peer, the message may include an Optional Parameter, called Capabilities. The parameter lists the capabilities supported by the speaker.
Chandra & Scudder Standards Track [Page 1]
RFC 2842 Capabilities Advertisement with BGP-4 May 2000
If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, the speaker may send a NOTIFICATION message to the peer, and terminate peering. The Error Subcode in the message is set to Unsupported Capability. The message should contain the capability (capabilities) that causes the speaker to send the message. The decision to send the message and terminate peering is local to the speaker. Such peering should not be re- established automatically.
2. Capabilities Optional Parameter (Parameter Type 2):
This is an Optional Parameter that is used by a BGP speaker to convey to its BGP peer the list of capabilities supported by the speaker.
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
The use and meaning of these fields are as follows:
Chandra & Scudder Standards Track [Page 2]
RFC 2842 Capabilities Advertisement with BGP-4 May 2000
Capability Value:
3. Extensions to Error Handling
This document defines new Error Subcode - Unsupported Capability. The value of this Subcode is 7. The Data field in the NOTIFICATION message lists the set of capabilities that cause the speaker to send the message. Each such capability is encoded the same way as it was encoded in the received OPEN message.
4. IANA Considerations
Section 4 defines a Capability Optional Parameter along with an Capability Code field. IANA is expected to create and maintain the registry for Capability Code values. Capability Code value 0 is reserved. Capability Code values 1 through 63 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC2434. Capability Code values 64 through 127 are to be assigned by IANA, using the "First Come First Served" policy defined in RFC2434. Capability Code values 128 through 255 are for "Private Use" as defined in RFC2434.
5. Security Considerations
This extension to BGP does not change the underlying security issues inherent in the existing BGP [Heffernan].
6. Acknowledgements
The authors would like to thank members of the IDR Working Group for their review and comments.
7. References
[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
Chandra & Scudder Standards Track [Page 3]
RFC 2842 Capabilities Advertisement with BGP-4 May 2000 8. Authors' AddressesRavi Chandra Redback Networks Inc. 350, Holger Way San Jose, CA 95134
Chandra & Scudder Standards Track [Page 4]
RFC 2842 Capabilities Advertisement with BGP-4 May 2000 9. Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved.