doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc2283.txt b/doc/rfc/rfc2283.txt
new file mode 100644
index 0000000..55002ef
--- /dev/null
+++ b/doc/rfc/rfc2283.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                           T. Bates
+Request for Comments: 2283                                 Cisco Systems
+Category: Standards Track                                     R. Chandra
+                                                           Cisco Systems
+                                                                 D. Katz
+                                                        Juniper Networks
+                                                              Y. Rekhter
+                                                           Cisco Systems
+                                                           February 1998
+
+
+                   Multiprotocol Extensions for 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 (1998).  All Rights Reserved.
+
+2. Abstract
+
+   Currently BGP-4 [BGP-4] is capable of carrying routing information
+   only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
+   enable it to carry routing information for multiple Network Layer
+   protocols (e.g., IPv6, IPX, etc...). The extensions are backward
+   compatible - a router that supports the extensions can interoperate
+   with a router that doesn't support the extensions.
+
+3. Overview
+
+   The only three pieces of information carried by BGP-4 that are IPv4
+   specific are (a) the NEXT_HOP attribute (expressed as an IPv4
+   address), (b) AGGREGATOR (contains an IPv4 address), and (c) NLRI
+   (expressed as IPv4 address prefixes). This document assumes that any
+   BGP speaker (including the one that supports multiprotocol
+   capabilities defined in this document) has to have an IPv4 address
+   (which will be used, among other things, in the AGGREGATOR
+   attribute). Therefore, to enable BGP-4 to support routing for
+   multiple Network Layer protocols the only two things that have to be
+   added to BGP-4 are (a) the ability to associate a particular Network
+   Layer protocol with the next hop information, and (b) the ability to
+   associated a particular Network Layer protocol with NLRI. To identify
+
+
+
+Bates, et. al.              Standards Track                     [Page 1]
+
+RFC 2283           Multiprotocol Extensions for BGP-4      February 1998
+
+
+   individual Network Layer protocols this document uses Address Family,
+   as defined in [RFC1700].
+
+   One could further observe that the next hop information (the
+   information provided by the NEXT_HOP attribute) is meaningful (and
+   necessary) only in conjunction with the advertisements of reachable
+   destinations - in conjunction with the advertisements of unreachable
+   destinations (withdrawing routes from service) the next hop
+   information is meaningless. This suggests that the advertisement of
+   reachable destinations should be grouped with the advertisement of
+   the next hop to be used for these destinations, and that the
+   advertisement of reachable destinations should be segregated from the
+   advertisement of unreachable destinations.
+
+   To provide backward compatibility, as well as to simplify
+   introduction of the multiprotocol capabilities into BGP-4 this
+   document uses two new attributes, Multiprotocol Reachable NLRI
+   (MP_REACH_NLRI), and Multiprotocol Unreachable NLRI
+   (MP_UNREACH_NLRI). The first one (MP_REACH_NLRI) is used to carry the
+   set of reachable destinations together with the next hop information
+   to be used for forwarding to these destinations. The second one
+   (MP_UNREACH_NLRI) is used to carry the set of unreachable
+   destinations.  Both of these attributes are optional and non-
+   transitive.  This way a BGP speaker that doesn't support the
+   multiprotocol capabilities will just ignore the information carried
+   in these attributes, and will not pass it to other BGP speakers.
+
+4. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14):
+
+   This is an optional non-transitive attribute that can be used for the
+   following purposes:
+
+      (a) to advertise a feasible route to a peer
+
+      (b) to permit a router to advertise the Network Layer address of
+      the router that should be used as the next hop to the destinations
+      listed in the Network Layer Reachability Information field of the
+      MP_NLRI attribute.
+
+      (c) to allow a given router to report some or all of the
+      Subnetwork Points of Attachment (SNPAs) that exist within the
+      local system
+
+   The attribute contains one or more triples <Address Family
+   Information, Next Hop Information, Network Layer Reachability
+   Information>, where each triple is encoded as shown below:
+
+
+
+
+
+Bates, et. al.              Standards Track                     [Page 2]
+
+RFC 2283           Multiprotocol Extensions for BGP-4      February 1998
+
+
+      +---------------------------------------------------------+
+      | Address Family Identifier (2 octets)                    |
+      +---------------------------------------------------------+
+      | Subsequent Address Family Identifier (1 octet)          |
+      +---------------------------------------------------------+
+      | Length of Next Hop Network Address (1 octet)            |
+      +---------------------------------------------------------+
+      | Network Address of Next Hop (variable)                  |
+      +---------------------------------------------------------+
+      | Number of SNPAs (1 octet)                               |
+      +---------------------------------------------------------+
+      | Length of first SNPA(1 octet)                           |
+      +---------------------------------------------------------+
+      | First SNPA (variable)                                   |
+      +---------------------------------------------------------+
+      | Length of second SNPA (1 octet)                         |
+      +---------------------------------------------------------+
+      | Second SNPA (variable)                                  |
+      +---------------------------------------------------------+
+      | ...                                                     |
+      +---------------------------------------------------------+
+      | Length of Last SNPA (1 octet)                           |
+      +---------------------------------------------------------+
+      | Last SNPA (variable)                                    |
+      +---------------------------------------------------------+
+      | Network Layer Reachability Information (variable)       |
+      +---------------------------------------------------------+
+
+   The use and meaning of these fields are as follows:
+
+      Address Family Identifier:
+
+         This field carries the identity of the Network Layer protocol
+         associated with the Network Address that follows. Presently
+         defined values for this field are specified in RFC1700 (see the
+         Address Family Numbers section).
+
+      Subsequent Address Family Identifier:
+
+         This field provides additional information about the type of
+         the Network Layer Reachability Information carried in the
+         attribute.
+
+      Length of Next Hop Network Address:
+
+         A 1 octet field whose value expresses the length of the
+         "Network Address of Next Hop" field as measured in octets
+
+
+
+
+Bates, et. al.              Standards Track                     [Page 3]
+
+RFC 2283           Multiprotocol Extensions for BGP-4      February 1998
+
+
+      Network Address of Next Hop:
+
+         A variable length field that contains the Network Address of
+         the next router on the path to the destination system
+
+      Number of SNPAs:
+
+         A 1 octet field which contains the number of distinct SNPAs to
+         be listed in the following fields.  The value 0 may be used to
+         indicate that no SNPAs are listed in this attribute.
+
+      Length of Nth SNPA:
+
+         A 1 octet field whose value expresses the length of the "Nth
+         SNPA of Next Hop" field as measured in semi-octets
+
+      Nth SNPA of Next Hop:
+
+         A variable length field that contains an SNPA of the router
+         whose Network Address is contained in the "Network Address of
+         Next Hop" field.  The field length is an integral number of
+         octets in length, namely the rounded-up integer value of one
+         half the SNPA length expressed in semi-octets; if the SNPA
+         contains an odd number of semi-octets, a value in this field
+         will be padded with a trailing all-zero semi-octet.
+
+      Network Layer Reachability Information:
+
+         A variable length field that lists NLRI for the feasible routes
+         that are being advertised in this attribute. When the
+         Subsequent Address Family Identifier field is set to one of the
+         values defined in this document, each NLRI is encoded as
+         specified in the "NLRI encoding" section of this document.
+
+   The next hop information carried in the MP_REACH_NLRI path attribute
+   defines the Network Layer address of the border router that should be
+   used as the next hop to the destinations listed in the MP_NLRI
+   attribute in the UPDATE message.  When advertising a MP_REACH_NLRI
+   attribute to an external peer, a router may use one of its own
+   interface addresses in the next hop component of the attribute,
+   provided the external peer to which the route is being advertised
+   shares a common subnet with the next hop address.  This is known as a
+   "first party" next hop.  A BGP speaker can advertise to an external
+   peer an interface of any internal peer router in the next hop
+   component, provided the external peer to which the route is being
+   advertised shares a common subnet with the next hop address.  This is
+   known as a "third party" next hop information.  A BGP speaker can
+   advertise any external peer router in the next hop component,
+
+
+
+Bates, et. al.              Standards Track                     [Page 4]
+
+RFC 2283           Multiprotocol Extensions for BGP-4      February 1998
+
+
+   provided that the Network Layer address of this border router was
+   learned from an external peer, and the external peer to which the
+   route is being advertised shares a common subnet with the next hop
+   address.  This is a second form of "third party" next hop
+   information.
+
+   Normally the next hop information is chosen such that the shortest
+   available path will be taken.  A BGP speaker must be able to support
+   disabling advertisement of third party next hop information to handle
+   imperfectly bridged media or for reasons of policy.
+
+   A BGP speaker must never advertise an address of a peer to that peer
+   as a next hop, for a route that the speaker is originating.  A BGP
+   speaker must never install a route with itself as the next hop.
+
+   When a BGP speaker advertises the route to an internal peer, the
+   advertising speaker should not modify the next hop information
+   associated with the route.  When a BGP speaker receives the route via
+   an internal link, it may forward packets to the next hop address if
+   the address contained in the attribute is on a common subnet with the
+   local and remote BGP speakers.
+
+   An UPDATE message that carries the MP_REACH_NLRI must also carry the
+   ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP
+   exchanges).  Moreover, in IBGP exchanges such a message must also
+   carry the LOCAL_PREF attribute. If such a message is received from an
+   external peer, the local system shall check whether the leftmost AS
+   in the AS_PATH attribute is equal to the autonomous system number of
+   the peer than sent the message. If that is not the case, the local
+   system shall send the NOTIFICATION message with Error Code UPDATE
+   Message Error, and the Error Subcode set to Malformed AS_PATH.
+
+5. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15):
+
+   This is an optional non-transitive attribute that can be used for the
+   purpose of withdrawing multiple unfeasible routes from service.
+
+   The attribute contains one or more triples <Address Family
+   Information, Unfeasible Routes Length, Withdrawn Routes>, where each
+   triple is encoded as shown below:
+
+      +---------------------------------------------------------+
+      | Address Family Identifier (2 octets)                    |
+      +---------------------------------------------------------+
+      | Subsequent Address Family Identifier (1 octet)          |
+      +---------------------------------------------------------+
+      | Withdrawn Routes (variable)                             |
+      +---------------------------------------------------------+
+
+
+
+Bates, et. al.              Standards Track                     [Page 5]
+
+RFC 2283           Multiprotocol Extensions for BGP-4      February 1998
+
+
+   The use and the meaning of these fields are as follows:
+
+      Address Family Identifier:
+
+         This field carries the identity of the Network Layer protocol
+         associated with the NLRI that follows. Presently defined values
+         for this field are specified in RFC1700 (see the Address Family
+         Numbers section).
+
+      Subsequent Address Family Identifier:
+
+         This field provides additional information about the type of
+         the Network Layer Reachability Information carried in the
+         attribute.
+
+      Withdrawn Routes:
+
+         A variable length field that lists NLRI for the routes that are
+         being withdrawn from service. When the Subsequent Address
+         Family Identifier field is set to one of the values defined in
+         this document, each NLRI is encoded as specified in the "NLRI
+         encoding" section of this document.
+
+   An UPDATE message that contains the MP_UNREACH_NLRI is not required
+   to carry any other path attributes.
+
+6. NLRI encoding
+
+   The Network Layer Reachability information is encoded as one or more
+   2-tuples of the form <length, prefix>, whose fields are described
+   below:
+
+      +---------------------------+
+      |   Length (1 octet)        |
+      +---------------------------+
+      |   Prefix (variable)       |
+      +---------------------------+
+
+   The use and the meaning of these fields are as follows:
+
+      a) Length:
+
+         The Length field indicates the length in bits of the address
+         prefix. A length of zero indicates a prefix that matches all
+         (as specified by the address family) addresses (with prefix,
+         itself, of zero octets).
+
+
+
+
+
+Bates, et. al.              Standards Track                     [Page 6]
+
+RFC 2283           Multiprotocol Extensions for BGP-4      February 1998
+
+
+      b) Prefix:
+
+         The Prefix field contains address prefixes followed by enough
+         trailing bits to make the end of the field fall on an octet
+         boundary.  Note that the value of trailing bits is irrelevant.
+
+7. Subsequent Address Family Identifier
+
+   This document defines the following values for the Subsequent Address
+   Family Identifier field carried in the MP_REACH_NLRI and
+   MP_UNREACH_NLRI attributes:
+
+      1 - Network Layer Reachability Information used for unicast
+          forwarding
+
+      2 - Network Layer Reachability Information used for multicast
+          forwarding
+
+      3 - Network Layer Reachability Information used for both unicast
+          and multicast forwarding
+
+   This document reserves values 128-255 for vendor-specific
+   applications.
+
+   This document reserves value 0.
+
+   Subsequent Address Family Identifiers (other than those reserved for
+   vendor specific use) are assigned only by the IETF consensus process
+   and IESG approval.
+
+8. Security Considerations
+
+   This extension to BGP does not change the underlying security issues.
+
+9. Acknowledgements
+
+   The authors would like to thank members of the IDR Working Group for
+   their review and comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bates, et. al.              Standards Track                     [Page 7]
+
+RFC 2283           Multiprotocol Extensions for BGP-4      February 1998
+
+
+10. References
+
+   [BGP-4]   Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
+             (BGP-4)", RFC 1771, March 1995.
+
+   [IPv4]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+             September 1981.
+
+   [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers," STD 2,
+             RFC 1700, October 1994. (see also
+             http://www.iana.org/iana/assignments.html)
+
+11. Author Information
+
+   Tony Bates
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   EMail: tbates@cisco.com
+
+
+   Ravi Chandra
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   EMail: rchandra@cisco.com
+
+
+   Dave Katz
+   Juniper Networks, Inc.
+   3260 Jay St.
+   Santa Clara, CA 95054
+
+   EMail: dkatz@jnx.com
+
+
+   Yakov Rekhter
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   EMail: yakov@cisco.com
+
+
+
+
+
+
+
+Bates, et. al.              Standards Track                     [Page 8]
+
+RFC 2283           Multiprotocol Extensions for BGP-4      February 1998
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bates, et. al.              Standards Track                     [Page 9]
+