a different proposal for ipv6 in bgp

John W. Stewart III jstewart@metro.isi.edu
Mon, 30 Dec 1996 14:05:41 EST


attached below is a proposal for a multi-protocol (including
ipv6) bgp

while there are a number of differences between this one and
the bates/chandra/katz/rekhter one, one of the main motivating
factors for this one is to support longer-than-two-byte ASs.
it is our view that making bgp multi-protocol significantly
extends its life.  so, although in a narrow sense the length
of the AS is orthogonal to being multi-protocol, the logistics
of transitions and the need to adequeately engineer the
protocol up-front, to us, suggests the need for longer-than-
two-byte ASs

/jws

##################################################################


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