Multiprotocol Extensions for BGP-4
RFC 2858

Document Type RFC - Proposed Standard (June 2000; Errata)
Obsoleted by RFC 4760
Obsoletes RFC 2283
Authors Yakov Rekhter  , Tony Bates  , Ravi Chandra  , Dave Katz 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2858 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           T. Bates
Request for Comments: 2858                                    Y. Rekhter
Obsoletes: 2283                                            Cisco Systems
Category: Standards Track                                     R. Chandra
                                                    Redback Networks Inc
                                                                 D. Katz
                                                        Juniper Networks
                                                               June 2000

                   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 (2000).  All Rights Reserved.


   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.

   This document obsoletes RFC 2283.

1. 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

Bates, et al.               Standards Track                     [Page 1]
RFC 2858           Multiprotocol Extensions for BGP-4          June 2000

   associated a particular Network Layer protocol with NLRI. To identify
   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.

2. 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

Bates, et al.               Standards Track                     [Page 2]
RFC 2858           Multiprotocol Extensions for BGP-4          June 2000

   The attribute is encoded as shown below:

Show full document text