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
datatracker.ietf.org