rfc-2858

Multiprotocol Extensions for BGP-4

T. Bates, Y. Rekhter, R. Chandra, D. Katz
date2000-06 streamIETF areartg wgidr statusPROPOSED STANDARD pages11 canonicalhttps://www.rfc-editor.org/rfc/rfc2858 doi10.17487/RFC2858 errataview
This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). [STANDARDS-TRACK]

obsoleted by

obsoletes

Extracted elements (27)

design-rationale §1

Address Family Identifier (from RFC 1700 Assigned Numbers) is used to identify individual Network Layer protocols rather than inventing a new identifier space, reusing an existing IANA-maintained registry.

bgp, routing, registry

design-rationale §1

MP_REACH_NLRI and MP_UNREACH_NLRI are optional and non-transitive to provide backward compatibility: a BGP speaker that does not support the multiprotocol extensions will simply ignore these attributes and not propagate them to other speakers.

bgp, routing

design-rationale §1

Reachable destinations are grouped with next hop information in MP_REACH_NLRI and segregated from unreachable destinations (MP_UNREACH_NLRI) because next hop information is meaningful only in conjunction with reachable destination advertisements.

bgp, routing

interoperability-note §7

A BGP speaker that uses Multiprotocol Extensions SHOULD use Capability Advertisement procedures (RFC 2842) to determine whether a particular peer supports the extensions before using them.

bgp, routing

interoperability-note §9

Compared to RFC 2283, this document restricts MP_REACH_NLRI and MP_UNREACH_NLRI to carry only a single instance of <AFI, SAFI, ...> per attribute, clarifying the encoding and simplifying implementation.

bgp, routing

interoperability-note §1

The extensions are backward compatible: a router that supports multiprotocol extensions can interoperate with a router that does not, as the new attributes are optional and non-transitive and will be silently ignored by non-supporting peers.

bgp, routing

normative-requirement §2 MUST

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.

bgp, routing

normative-requirement §2 MUST NOT

A BGP speaker must never advertise an address of a peer to that peer as a next hop for a route the speaker is originating, and must never install a route with itself as the next hop.

bgp, routing

normative-requirement §2 MUST

An UPDATE message that carries MP_REACH_NLRI MUST also carry the ORIGIN and AS_PATH attributes in both EBGP and IBGP exchanges. In IBGP exchanges, such a message MUST also carry the LOCAL_PREF attribute.

bgp, routing

normative-requirement §2 SHOULD NOT

An UPDATE message that carries no NLRI other than that encoded in MP_REACH_NLRI SHOULD NOT carry the NEXT_HOP attribute; if it does, the receiving BGP speaker SHOULD ignore the NEXT_HOP attribute.

bgp, routing

normative-requirement §3 OPTIONAL

An UPDATE message that contains MP_UNREACH_NLRI is not required to carry any other path attributes.

bgp, routing

normative-requirement §6 MUST

If a BGP speaker receives an UPDATE with an incorrect MP_REACH_NLRI or MP_UNREACH_NLRI attribute, it MUST delete all BGP routes from that neighbor with the same AFI/SAFI, and SHOULD ignore all subsequent routes with that AFI/SAFI for the duration of the session.

bgp, routing

normative-requirement §2 REQUIRED

If an EBGP UPDATE with MP_REACH_NLRI is received and the leftmost AS in AS_PATH does not match the peer's AS number, the local system SHALL send a NOTIFICATION with Error Code UPDATE Message Error and Subcode Malformed AS_PATH.

bgp, routing, security

normative-requirement §6 MAY

In response to an incorrect MP_REACH_NLRI or MP_UNREACH_NLRI, the speaker MAY terminate the BGP session, and if so SHOULD send a Notification with code/subcode 'Update Message Error'/'Optional Attribute Error'.

bgp, routing

normative-requirement §7 MUST

To support a bidirectional exchange of routing information for a particular <AFI, SAFI> pair, each BGP speaker MUST advertise to the other (via Capability Advertisement) the capability to support that <AFI, SAFI>.

bgp, routing

normative-requirement §2 SHOULD NOT

When advertising a route to an internal peer, the advertising speaker SHOULD NOT modify the next hop information associated with the route.

bgp, routing

protocol-element §2

MP_REACH_NLRI (Type Code 14) is an optional non-transitive BGP path attribute used to advertise feasible routes together with next hop information for multiple Network Layer protocols. It carries AFI, SAFI, next hop address, optional SNPAs, and NLRI.

bgp, ip, routing

protocol-element §3

MP_UNREACH_NLRI (Type Code 15) is an optional non-transitive BGP path attribute used to withdraw multiple unfeasible routes from service for multiple Network Layer protocols. It carries AFI, SAFI, and withdrawn routes.

bgp, ip, routing

protocol-element §5

The Subsequent Address Family Identifier (SAFI) field provides additional type information for NLRI: value 1 for unicast forwarding, value 2 for multicast forwarding, and value 3 for both unicast and multicast forwarding.

bgp, routing, multicast

protocol-element §2

Third-party next hop rules: a BGP speaker may advertise an internal peer's interface as next hop to an external peer if they share a common subnet, or may advertise an external peer router's address as next hop if that address was learned from an external peer and shares a common subnet with the destination peer.

bgp, routing

registry §8

The SAFI (Subsequent Address Family Identifier) namespace is defined: value 0 is reserved; values 1-3 assigned by this document; values 4-63 assigned by IANA using IETF Consensus; values 64-127 by First Come First Served; values 128-255 for private use.

bgp, routing, registry

security-consideration §10

The multiprotocol extensions to BGP-4 do not change the underlying security issues inherent in the existing BGP protocol. Security for BGP sessions is addressed via the TCP MD5 Signature Option [RFC 2385].

bgp, security

wire-format §2

MP_REACH_NLRI is encoded as: AFI (2 octets), SAFI (1 octet), Length of Next Hop Network Address (1 octet), Network Address of Next Hop (variable), Number of SNPAs (1 octet), followed by variable-length SNPA entries, and Network Layer Reachability Information (variable).

bgp, routing

wire-format §3

MP_UNREACH_NLRI is encoded as: AFI (2 octets), SAFI (1 octet), and Withdrawn Routes (variable). The Withdrawn Routes field lists NLRI encoded as <length, prefix> 2-tuples.

bgp, routing

wire-format §4

NLRI is encoded as one or more 2-tuples of <Length (1 octet), Prefix (variable)>. Length specifies the prefix length in bits; a length of zero matches all addresses. The Prefix field is padded with trailing bits to an octet boundary.

bgp, routing, ip

wire-format §2

SNPA length is expressed in semi-octets; the encoded SNPA field is rounded up to an integral number of octets, with a trailing all-zero semi-octet pad if the SNPA contains an odd number of semi-octets.

bgp, routing

wire-format §7

The BGP Capability Value for Multiprotocol Extensions (Capability Code 1, Length 4) encodes: AFI (16 bits), Reserved (8 bits, set to 0 by sender and ignored by receiver), and SAFI (8 bits).

bgp, routing