From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2842.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc2842.txt (limited to 'doc/rfc/rfc2842.txt') diff --git a/doc/rfc/rfc2842.txt b/doc/rfc/rfc2842.txt new file mode 100644 index 0000000..3720ae9 --- /dev/null +++ b/doc/rfc/rfc2842.txt @@ -0,0 +1,283 @@ + + + + + + +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 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + Currently BGP-4 [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. + +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. + + A BGP speaker determines the capabilities supported by its peer by + examining the list of capabilities present in the Capabilities + Optional Parameter carried by the OPEN message that the speaker + receives from the peer. + + A BGP speaker that supports a particular capability may use this + capability with its peer after the speaker determines (as described + above) that the peer supports this capability. + + + +Chandra & Scudder Standards Track [Page 1] + +RFC 2842 Capabilities Advertisement with BGP-4 May 2000 + + + A BGP speaker determines that its peer doesn't support capabilities + advertisement, if in response to an OPEN message that carries the + Capabilities Optional Parameter, the speaker receives a NOTIFICATION + message with the Error Subcode set to Unsupported Optional Parameter. + In this case the speaker should attempt to re-establish a BGP + connection with the peer without sending to the peer the Capabilities + Optional Parameter. + + 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. + + The parameter contains one or more triples , where each triple is encoded as + shown below: + + +------------------------------+ + | Capability Code (1 octet) | + +------------------------------+ + | Capability Length (1 octet) | + +------------------------------+ + | Capability Value (variable) | + +------------------------------+ + + The use and meaning of these fields are as follows: + + Capability Code: + + Capability Code is a one octet field that unambiguously + identifies individual capabilities. + + Capability Length: + + Capability Length is a one octet field that contains the length + of the Capability Value field in octets. + + + + + + +Chandra & Scudder Standards Track [Page 2] + +RFC 2842 Capabilities Advertisement with BGP-4 May 2000 + + + Capability Value: + + Capability Value is a variable length field that is interpreted + according to the value of the Capability Code field. + + A particular capability, as identified by its Capability Code, may + occur more than once within the Optional Parameter. + +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 + (BGP-4)", RFC 1771, March 1995. + + [Heffernan] Heffernan, A., "Protection of BGP Sessions via the TCP + MD5 Signature Option", RFC 2385, August 1998. + + + + + + + +Chandra & Scudder Standards Track [Page 3] + +RFC 2842 Capabilities Advertisement with BGP-4 May 2000 + + +8. Authors' Addresses + + Ravi Chandra + Redback Networks Inc. + 350, Holger Way + San Jose, CA 95134 + + EMail: rchandra@redback.com + + + John G. Scudder + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134 + + EMail: jgs@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Chandra & Scudder Standards Track [Page 4] + +RFC 2842 Capabilities Advertisement with BGP-4 May 2000 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Chandra & Scudder Standards Track [Page 5] + -- cgit v1.2.3