Multiprotocol Extensions for BGP-4
RFC 4760

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 10

Network Working Group                                           T. Bates
Request for Comments: 4760                                 Cisco Systems
Obsoletes: 2858                                               R. Chandra
Category: Standards Track                                  Sonoa Systems
                                                                 D. Katz
                                                              Y. Rekhter
                                                        Juniper Networks
                                                            January 2007

                   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 IETF Trust (2007).

Abstract

   This document defines extensions to BGP-4 to enable it to carry
   routing information for multiple Network Layer protocols (e.g., IPv6,
   IPX, L3VPN, etc.).  The extensions are backward compatible - a router
   that supports the extensions can interoperate with a router that
   doesn't support the extensions.

Bates, et al.               Standards Track                     [Page 1]
RFC 4760           Multiprotocol Extensions for BGP-4       January 2007

1.  Introduction

   The only three pieces of information carried by BGP-4 [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
   associate a particular Network Layer protocol with NLRI.  To identify
   individual Network Layer protocols associated with the next hop
   information and semantics of NLRI, this document uses a combination
   of Address Family, as defined in [IANA-AF], and Subsequent Address
   Family (as described in this document).

   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.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Bates, et al.               Standards Track                     [Page 2]
RFC 4760           Multiprotocol Extensions for BGP-4       January 2007

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

   The attribute is encoded as shown below: