Expiration Date July 2001                                       [Page 6]RFC DRAFT                                                   January 20014.1 Message Header Format   Each message has a fixed-size header.  There may or may not be a data   portion following the header, depending on the message type.  The   layout of these fields is shown below:       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     |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      Marker:         This 16-octet field contains a value that the receiver of the         message can predict.  If the Type of the message is OPEN, or if         the OPEN message carries no Authentication Information (as an         Optional Parameter), then the Marker must be all ones.         Otherwise, the value of the marker can be predicted by some a         computation specified as part of the authentication mechanism         (which is specified as part of the Authentication Information)         used.  The Marker can be used to detect loss of synchronization         between a pair of BGP peers, and to authenticate incoming BGP         messages.      Length:         This 2-octet unsigned integer indicates the total length of the         message, including the header, in octets.  Thus, e.g., it         allows one to locate in the transport-level stream the (Marker         field of the) next message.  The value of the Length field mustExpiration Date July 2001                                       [Page 7]RFC DRAFT                                                   January 2001         always be at least 19 and no greater than 4096, and may be         further constrained, depending on the message type.  No         "padding" of extra data after the message is allowed, so the         Length field must have the smallest value required given the         rest of the message.      Type:         This 1-octet unsigned integer indicates the type code of the         message.  The following type codes are defined:                                    1 - OPEN                                    2 - UPDATE                                    3 - NOTIFICATION                                    4 - KEEPALIVE4.2 OPEN Message Format   After a transport protocol connection is established, the first   message sent by each side is an OPEN message.  If the OPEN message is   acceptable, a KEEPALIVE message confirming the OPEN is sent back.   Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION   messages may be exchanged.   In addition to the fixed-size BGP header, the OPEN message contains   the following fields:        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       +-+-+-+-+-+-+-+-+       |    Version    |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |     My Autonomous System      |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |           Hold Time           |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |                         BGP Identifier                        |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       | Opt Parm Len  |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |                                                               |       |                       Optional Parameters                     |       |                                                               |Expiration Date July 2001                                       [Page 8]RFC DRAFT                                                   January 2001       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      Version:         This 1-octet unsigned integer indicates the protocol version         number of the message.  The current BGP version number is 4.      My Autonomous System:         This 2-octet unsigned integer indicates the Autonomous System         number of the sender.      Hold Time:         This 2-octet unsigned integer indicates the number of seconds         that the sender proposes for the value of the Hold Timer.  Upon         receipt of an OPEN message, a BGP speaker MUST calculate the         value of the Hold Timer by using the smaller of its configured         Hold Time and the Hold Time received in the OPEN message.  The         Hold Time MUST be either zero or at least three seconds.  An         implementation may reject connections on the basis of the Hold         Time.  The calculated value indicates the maximum number of         seconds that may elapse between the receipt of successive         KEEPALIVE, and/or UPDATE messages by the sender.      BGP Identifier:         This 4-octet unsigned integer indicates the BGP Identifier of         the sender. A given BGP speaker sets the value of its BGP         Identifier to an IP address assigned to that BGP speaker.  The         value of the BGP Identifier is determined on startup and is the         same for every local interface and every BGP peer.      Optional Parameters Length:         This 1-octet unsigned integer indicates the total length of the         Optional Parameters field in octets. If the value of this field         is zero, no Optional Parameters are present.      Optional Parameters:         This field may contain a list of optional parameters, where         each parameter is encoded as a <Parameter Type, Parameter         Length, Parameter Value> triplet.Expiration Date July 2001                                       [Page 9]RFC DRAFT                                                   January 2001                0                   1                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...               |  Parm. Type   | Parm. Length  |  Parameter Value (variable)               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...         Parameter Type is a one octet field that unambiguously         identifies individual parameters. Parameter Length is a one         octet field that contains the length of the Parameter Value         field in octets.  Parameter Value is a variable length field         that is interpreted according to the value of the Parameter         Type field.         This document defines the following Optional Parameters:         a) Authentication Information (Parameter Type 1):            This optional parameter may be used to authenticate a BGP            peer. The Parameter Value field contains a 1-octet            Authentication Code followed by a variable length            Authentication Data.                0 1 2 3 4 5 6 7 8                +-+-+-+-+-+-+-+-+                |  Auth. Code   |                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                |                                                     |                |              Authentication Data                    |                |                                                     |                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               Authentication Code:                  This 1-octet unsigned integer indicates the                  authentication mechanism being used.  Whenever an                  authentication mechanism is specified for use within                  BGP, three things must be included in the                  specification:                  - the value of the Authentication Code which indicates                  use of the mechanism,                  - the form and meaning of the Authentication Data, and                  - the algorithm for computing values of Marker fields.Expiration Date July 2001                                      [Page 10]RFC DRAFT                                                   January 2001                  Note that a separate authentication mechanism may be                  used in establishing the transport level connection.               Authentication Data:                  Authentication Data is a variable length field that is                  interpreted according to the value of the                  Authentication Code field.         The minimum length of the OPEN message is 29 octets (including         message header).4.3 UPDATE Message Format   UPDATE messages are used to transfer routing information between BGP   peers.  The information in the UPDATE packet can be used to construct   a graph describing the relationships of the various Autonomous   Systems.  By applying rules to be discussed, routing information   loops and some other anomalies may be detected and removed from   inter-AS routing.   An UPDATE message is used to advertise a single feasible route to a   peer, or to withdraw multiple unfeasible routes from service (see   3.1). An UPDATE message may simultaneously advertise a feasible route   and withdraw multiple unfeasible routes from service.  The UPDATE   message always includes the fixed-size BGP header, and can optionally   include the other fields as shown below:      +-----------------------------------------------------+      |   Unfeasible Routes Length (2 octets)               |      +-----------------------------------------------------+      |  Withdrawn Routes (variable)                        |      +-----------------------------------------------------+      |   Total Path Attribute Length (2 octets)            |      +-----------------------------------------------------+      |    Path Attributes (variable)                       |      +-----------------------------------------------------+      |   Network Layer Reachability Information (variable) |      +-----------------------------------------------------+      Unfeasible Routes Length:Expiration Date July 2001                                      [Page 11]RFC DRAFT                                                   January 2001         This 2-octets unsigned integer indicates the total length of         the Withdrawn Routes field in octets.  Its value must allow the         length of the Network Layer Reachability Information field to         be determined as specified below.         A value of 0 indicates that no routes are being withdrawn from         service, and that the WITHDRAWN ROUTES field is not present in         this UPDATE message.      Withdrawn Routes:         This is a variable length field that contains a list of IP         address prefixes for the routes that are being withdrawn from         service.  Each IP address prefix is encoded as a 2-tuple of the         form <length, prefix>, whose fields are described below:                  +---------------------------+                  |   Length (1 octet)        |                  +---------------------------+                  |   Prefix (variable)       |                  +---------------------------+         The use and the meaning of these fields are as follows:         a) Length:            The Length field indicates the length in bits of the IP            address prefix. A length of zero indicates a prefix that