1 files changed, 283 insertions, 0 deletions
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 <Capability Code,
+   Capability Length, Capability Value>, 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]
+