rfc-2283

Multiprotocol Extensions for BGP-4

T. Bates, R. Chandra, D. Katz, Y. Rekhter
date1998-02 streamIETF areartg wgidr statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc2283 doi10.17487/RFC2283
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. [STANDARDS-TRACK]

obsoleted by

Extracted elements (20)

design-rationale §3

BGP-4 has only three IPv4-specific components: NEXT_HOP (IPv4 address), AGGREGATOR (contains IPv4 address), and NLRI (IPv4 prefixes). To support multiple network layer protocols, only two additions are needed: associating a network layer protocol with next hop information, and associating a network layer protocol with NLRI.

bgp, routing

design-rationale §3

Reachable destinations are grouped with next hop information (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

design-rationale §3

Two new optional non-transitive attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) are used to provide backward compatibility. A BGP speaker that does not support multiprotocol capabilities will simply ignore these attributes and not pass them to other BGP speakers.

bgp, routing

interoperability-note §4

First party and third party next hop advertisements are permitted when the external peer shares a common subnet with the next hop address; third party next hop advertisement can be disabled for imperfectly bridged media or policy reasons.

bgp, routing

interoperability-note §3

The extensions are backward compatible: a router supporting multiprotocol extensions can interoperate with a router that does not support them, because MP_REACH_NLRI and MP_UNREACH_NLRI are optional non-transitive attributes that unsupporting routers will ignore.

bgp, routing

normative-requirement §4 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 §4 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 §4 MUST

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

bgp, routing

normative-requirement §5 OPTIONAL

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

bgp, routing

normative-requirement §4 REQUIRED

If an UPDATE with MP_REACH_NLRI is received from an external peer and the leftmost AS in AS_PATH is not equal to the autonomous system number of the sending peer, the local system SHALL send a NOTIFICATION with Error Code UPDATE Message Error and Error Subcode set to Malformed AS_PATH.

bgp, routing, security

normative-requirement §4 SHOULD NOT

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

bgp, routing

protocol-element §4

MP_REACH_NLRI (Type Code 14) is an optional non-transitive BGP path attribute used to advertise feasible routes, the next hop network layer address, and Subnetwork Points of Attachment (SNPAs). It contains one or more triples of <Address Family Information, Next Hop Information, Network Layer Reachability Information>.

bgp, routing

protocol-element §5

MP_UNREACH_NLRI (Type Code 15) is an optional non-transitive BGP path attribute used to withdraw multiple unfeasible routes from service. It contains one or more triples of <Address Family Identifier, Subsequent Address Family Identifier, Withdrawn Routes>.

bgp, routing

protocol-element §4

The Address Family Identifier field carries the identity of the Network Layer protocol associated with the network address. Defined values are specified in RFC 1700 (Address Family Numbers section).

bgp, routing

protocol-element §4

The Subsequent Address Family Identifier (SAFI) field provides additional information about the type of Network Layer Reachability Information carried in MP_REACH_NLRI and MP_UNREACH_NLRI attributes.

bgp, routing

registry §7

This document defines Subsequent Address Family Identifier (SAFI) values: 1 for unicast forwarding, 2 for multicast forwarding, 3 for both unicast and multicast forwarding. Values 128-255 are reserved for vendor-specific applications. Value 0 is reserved. New SAFI values (other than vendor-specific) are assigned only by IETF consensus process and IESG approval.

bgp, routing, registry

security-consideration §8

This extension to BGP does not change the underlying security issues inherent in BGP-4; no new security mechanisms are introduced or required.

bgp, security, routing

wire-format §4

MP_REACH_NLRI encoding: 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), followed by length-prefixed SNPA fields (each length 1 octet in semi-octets, value variable), and finally Network Layer Reachability Information (variable).

bgp, routing

wire-format §5

MP_UNREACH_NLRI encoding: Address Family Identifier (2 octets), Subsequent Address Family Identifier (1 octet), Withdrawn Routes (variable), where Withdrawn Routes lists NLRI encoded as <length, prefix> 2-tuples.

bgp, routing

wire-format §6

NLRI encoding uses 2-tuples of <Length (1 octet, length in bits of address prefix), Prefix (variable, padded with trailing bits to octet boundary)>. A length of zero indicates a prefix matching all addresses with the prefix itself being zero octets.

bgp, routing