Browse Prior Art Database

Multiprotocol Extensions for BGP-4 (RFC2858)

IP.com Disclosure Number: IPCOM000003457D
Original Publication Date: 2000-Jun-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 11 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

T. Bates: AUTHOR [+3]

Related Documents

10.17487/RFC2858: DOI

Abstract

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]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 16% of the total text.

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.

Abstract

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

Processing...
Loading...