Network Working Group Dimitry Haskin Internet-Draft Bay Networks Expires June 1997 John W. Stewart, III ISI Multiprotocol Extensions for BGP draft-stewart-bgp-multiprotocol-00.txt 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document outlines a proposal for a BGP Version 5 (BGP5) which has the ability to carry routing information for a variety of network protocols. The proposed BGP modifications are intended to be simple enough to be easily added to the existing BGP implementations and, at the same time, provide for a longer than 16-bit AS number space. This document only describes BGP5 support for IPv4 and IPv6 networks. 3. Overview BGP [BGP4-RFC] is widely deployed as an inter-domain routing protocol for IPv4 and there is a large operational experience with it. Though currently BGP can only carry routing information for IPv4, the existence of the mature BGP implementation base provides a strong motivation for extending it to support the Internet Protocol version 6 (IPv6) and possibly other network protocols. This document outlines a proposal for creating a BGP Version 5 (BGP5) which has the ability to carry routing information for a variety of network protocols. Adding this multi-protocol support to BGP significantly increases its lifetime, so care should be taken for BGP5 to not be under-engineered. For this reason, BGP5 supports longer than 2-byte ASs. At the same time, in the authors' view, the proposed modifications are simple enough to be easily added to the existing BGP implementations as not to impede BGP5 deployment. As a matter of fact no changes to the BGP4 data structures are required to support IPv4 routing in BGP5. To ensure a smooth transition from BGP4 to BGP5 on IPv4 networks it is recommended that upgraded BGP implementations continue BGP4 support at least until BGP5 is universally deployed. The BGP5 proposal ensures that IPv4 routing information that is advertised with BGP5 is fully re-advertisable via BGP4 and vice versa. In this sense BGP4 and BGP5 are fully compatible as far as IPv4 routing is concerned. This paper presents an overview of the protocol messages used by BGP5. Where details of the protocol (e.g., the state machine and fields of protocol messages) have the same meaning as BGP4, those details are left out of this outline for the sake of brevity. 4. Autonomous System Number Space This document proposes to adopt a 32-bit Autonomous System number space for IPv6 to accommodate for the aggressive Internet growth. The 32-bit number space is large enough to ensure that no future IPv6 transition to a larger number space will be necessary. In order to minimize implementation changes that are needed to support IPv4 routing, 16-bit AS number space will continue to be supported with BGP5. In addition BGP5 will provide a mechanism to gradually introduce the 32-bit AS number space to IPv4 routing. 5. Message Formats This section describes message formats used by BGP. 5.1 Message Header Format The fixed header for BGP5 is the same as BGP4, namely: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | Marker | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is as described in BGP4. 5.2 OPEN Message Format The OPEN message has the following format: +---------------------------------------+ | Version (1 octet) | +---------------------------------------+ | Len of My Autonomous System (1 octet) | +---------------------------------------+ | My Autonomous System (variable) | +---------------------------------------+ | Hold Time (2 octets) | +---------------------------------------+ | Router ID (4 octets) | +---------------------------------------+ | Opt Parm Len (1 octet) | +---------------------------------------+ | Optional Parameters (variable) | +---------------------------------------+ "Version" is a one-octet unsigned integer specifying the protocol version. This paper describes BGP version 5. "Len of My Autonomous System" is a one-octet unsigned integer specifying the length in octets of the "My Autonomous System" field. To carry IPv4 ASs this field should be 2; to carry IPv6 ASs this field should be 4. The presence of this field permits routing domain identifiers of any length, though this paper only discusses the use of 2-byte ASs and 4-byte [fixed-length] ASs. "My Autonomous System" identifies the AS of which the sender is a member. "Hold Time" is as described in BGP4. "Router ID" is a 32-bit unsigned integer identifying the sender. Because the size of the Router ID is smaller than an IPv6 address, it cannot be set to one of the router's IPv6 addresses (as is commonly done for IPv4). Possible Router ID assignment procedures for IPv6 include: a) assign the IPv6 Router ID as one of the router's IPv4 addresses or b) assign IPv6 Router IDs through some local administrative procedure (similar to procedures used by manufacturers to assign product serial numbers). The Router ID of 0.0.0.0 is reserved, and should not be used. "Opt Parm Len" and "Optional Parameters" are as described in BGP4. 5.3 UPDATE Message Format The UPDATE message always includes the fixed-size BGP header that is followed by one-octet Format Type field which indicates the format and content of the rest of the UPDATE message. The following UPDATE Format Type values are defined in this document: 1 - BGP4 compatible update with IPv4 routing information 2 - IPv6 routing update 3 - IPv4 routing update with the 4-octet AS numbers Implementations are not required to support all possible update formats. To allow for future enhancements, implementations are required to ignore UPDATES with format types that they do not support. 5.3.1 BGP4 Compatible Update This type of UPDATE message has the following format: +-----------------------------------------------------+ | Format Type (1 octet) == 1 | +-----------------------------------------------------+ | Withdrawn Routes Length (2 octets) | +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+ | Total Path Attribute Length (2 octets) | +-----------------------------------------------------+ | Path Attributes (variable) | +-----------------------------------------------------+ | Network Layer Reachability Information (variable) | +-----------------------------------------------------+ "Format Type" is a value indicating the format of the UPDATE message. It is 1 for the BGP4 compatible format type. All other fields are as described in BGP4. 5.3.2 IPv6 Routing Update This type of UPDATE message has the following format: +-----------------------------------------------------+ | Format Type (1 octet) == 2 | +-----------------------------------------------------+ | Withdrawn Routes Length (2 octets) | +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+ | Total Path Attribute Length (2 octets) | +-----------------------------------------------------+ | Path Attributes (variable) | +-----------------------------------------------------+ | Network Layer Reachability Information (variable) | +-----------------------------------------------------+ "Format Type" is a value indicating the format of the UPDATE message. It is 2 for UPDATE messages that carry IPv6 routes. "Withdrawn Routes Length" is a two-octet unsigned integer specifying the length in octets of the "Withdrawn Routes" field. "Withdrawn Routes" is a variable-length field containing a list of address prefixes being withdrawn from service. Each address prefix is encoded as described in BGP4, except that the "Length" component of the tuple isn't limited to what would make sense for IPv4 addresses. "Total Path Attribute Length" is as described in BGP4. "Path Attributes" field is as described in BGP4 except: - The NEXT-HOP attribute is interpreted as a 16-byte IPv6 global or site scope address. - The AGGREGATOR attribute contains the AS number that formed the aggregate route (encoded as 4 octets), followed by the 16-byte IPv6 global or site scope address of the BGP speaker that formed the aggregate route. - The AS-PATH attribute contains four-byte ASs. Two-byte ASs can be mapped to four-byte ASs with zero-padding to the left. - A new LINK-LOCAL-NEXT-HOP attribute. LINK-LOCAL-NEXT-HOP is a well-known discretionary attribute that contains the link-local address of the router interface associated with the global-scope IPv6 address specified in the NEXT-HOP attribute of the same UPDATE message. LINK-LOCAL-NEXT-HOP shall be included in all IPv6 UPDATE messages that a given BGP speaker sends to other BGP speakers located in a neighboring autonomous system. Such a link local address should be used as the immediate next hop for forwarding packets to the destinations listed in the UPDATE message. A BGP speaker shall not include this attribute in IPv6 UPDATE messages that it sends to BGP speakers located in its own autonomous system. If it is contained in an UPDATE message that is received from a BGP speaker which is located in the same AS as the receiving speaker, then this attribute shall be ignored by the receiving speaker. For the routes received from a BGP speaker in the same AS as the receiving speaker, the link-local address of the immediate next hop should be based on the IGP route to the global-scope address provided in the NEXT-HOP attribute. "Network Layer Reachability Information" is as described in BGP4, except that the "Length" component of the tuple isn't limited to what would make sense for IPv4 addresses. 5.3.3 IPv4 Routing Update With the 32-bit AS Numbers This type of UPDATE message provides support for a larger than 16-bit AS number space that is currently supported in BGP4. Introducing this type of UPDATE well in advance of the 16-bit AS number space exhaustion will allow for smoother IPv4 transition to a larger AS number space. 16-bit AS numbers can be mapped into 32-bit AS numbers by with zero-padding to the left. Therefore it is expected that for an extended period, until BGP5 which supports this type of UPDATE message is universally deployed, bacwards compatibility will be achieved by simply mapping 16-bit AS numbers to zero- extended 32-bit AS numbers and vice versa. This type of UPDATE message has the following format: +-----------------------------------------------------+ | Format Type (1 octet) == 3 | +-----------------------------------------------------+ | Withdrawn Routes Length (2 octets) | +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+ | Total Path Attribute Length (2 octets) | +-----------------------------------------------------+ | Path Attributes (variable) | +-----------------------------------------------------+ | Network Layer Reachability Information (variable) | +-----------------------------------------------------+ "Format Type" is a value indicating the format of the UPDATE message. It is 3 for this format type. "Withdrawn Routes Length" is as described in BGP4. "Withdrawn Routes" is as described in BGP4 "Total Path Attribute Length" is as described in BGP4. "Path Attributes" field is as described in BGP4 except: - The AGGREGATOR attribute contains the 32-bit AS number that formed the aggregate route (encoded as 4 octets), followed by the IPv4 address of the BGP speaker that formed the aggregate route. - The AS-PATH attribute contains 32-bit ASs. 6. Acknowledgements [TBA] 7. Security Considerations [TBA] 8. References [BGP4-RFC] -- RFC1771 [ASSIGNED-NUMBERS-RFC] -- RFC1700 9. Authors' Addresses John W. Stewart, III USC/ISI 4350 North Fairfax Drive Suite 620 Arlington, VA 22203 +1 703 812 3704 email: jstewart@isi.edu Dimitry Haskin Bay Networks 2 Federal St. Billerica, MA +1 508 916 8124 email: dhaskin@baynetworks.com