8.4. BGP-4 Support for IPv6
There is no actual BGP for IPv6. The IPv6 support derives from the capability of BGP-4 to exchange information about network layer protocols other than IPv4. These multiprotocol extensions of BGP-4 are defined in RFC 2858, which obsoletes RFC 2283. RFC 2283 is mentioned here because it is the base document for RFC 2545, which defines the IPv6 extensions for BGP-4. It is important to understand BGP-4 fully before looking at its multiprotocol extensions. The following sections start with a short overview of BGP-4 and its operations as defined in RFC 4271 (formerly RFC 1771). BGP message types are then discussed. The last part covers the implementation of IPv6 information carried within BGP-4.
8.4.1. BGP-4 Overview
Each AS runs its interior routing protocol (RIP, OSPF, etc.) to distribute all routing information within the AS. The BGP is an exterior routing protocol whose primary function is to exchange information about the reachability of networks between ASes. Each AS receives a unique AS number assigned by the numbering authority. Figure 8-34 shows the different types of ASes that can be interconnected using BGP-4.
Figure 8-34. BGP traffic and AS types
The AS types are further explained in the following list:
Two routers exchanging routing information with BGP are called BGP peers, BGP speakers, or BGP neighbors. They first establish a TCP connection to ensure reliable transport. The peers then open the actual BGP connection to exchange BGP messages. The most important BGP message is the UPDATE message, which contains the routes to be exchanged. A BGP route is defined as a unit of information consisting of the Network Layer Reachability Information (NLRI) and a set of path attributes. The NLRI is basically an IPv4 prefix and its prefix length. Any concept of IPv4 class information has been eliminated. The NLRI may represent a single network or, more commonly, an aggregate (summary) of a range of addresses. Each NLRI is accompanied by a set of path attributes that add additional information to the BGP route, i.e., the next hop address, a sequence of ASes through which the route has passed during its update, or its origin. Routing decisions and traffic management are often based on these path attributes. One attribute must be emphasized here, as it plays a very important role in loop detection: it is called AS_PATH, and it carries a sequence of AS numbers through which the route has passed. If the receiving peer recognizes its own AS number within the AS_PATH, it rejects the corresponding route.
BGP routing updates are exchanged between two peers. They are governed by policies. Outbound policies specify which NLRIs are advertised to a particular peer. A router can advertise only the BGP routes it uses itself. Inbound policies specify which BGP routes are accepted from a particular peer. Policies may also be used to modify a BGP route (including its attributes), to change its characteristics.
22.214.171.124. Establishing a BGP connection
In order to exchange routing updates, two peers first have to establish a BGP connection. Figure 8-35 illustrates the steps needed to establish a BGP connection, including the different BGP messages exchanged and the peer state. The entire state machine is explained in detail in RFC 4271. Each message and its fields are explained in the upcoming section "BGP Message Header."
Figure 8-35. Establishing a BGP connection
To initiate and establish a BGP connection, the peers use the BGP OPEN message. If both routers simultaneously try to establish a BGP connection to each other, two parallel connections might well be formed. To avoid this connection collision, one router has to back down. The connection initiated by the router with the higher BGP Identifier prevails. The BGP Identifier is uniquely assigned to each BGP router and is exchanged during the OPEN message. Once the open is confirmed, the routers exchange the entire routing table based on their policies. Only changes in the routing table are exchanged from now on. Routing exchanges are done using BGP UPDATE messages. BGP KEEPALIVE messages prevent the connection from timing out. The TCP session guarantees reliable delivery of each BGP message.
BGP distinguishes between the following peer connections:
BGP NOTIFICATION messages inform the peers of any errors during the open or update process. The connection can be shut down in a controlled fashion using a cease NOTIFICATION message.
126.96.36.199. Route storage and policies
BGP routes are stored in a Routing Information Base (RIB). Figure 8-36 shows the three different RIBs and their interactions.
Figure 8-36. BGP RIBs and their interactions
Incoming messages could contain new feasible routes, replacement routes of earlier updates, or routes that have been withdrawn by the advertising peer. All these routes are placed into the Adj-RIB-In. For each new or changed route, a degree of preference is calculated based on the inbound policy. This preference is placed into the attribute LOCAL_PREF. If the route arrives from an internal peer, the LOCAL_PREF is already carried in the update and should not be recalculated. Each route in the Adj-RIB-In is now processed by the route selection process and entered into the Loc-RIB. The selection process first looks at the NEXT_HOP and AS_PATH attributes of the route. The IP address specified by the NEXT_HOP must be reachable through an entry in the local routing table. The AS_PATH must not contain the local AS number. If the two attributes comply, the route is accepted or ignored based on the inbound policy; otherwise, the route is ignored. In case of multiple routes to the same destination, the route with the highest preference is accepted. In case of the same preference, a complex tie-breaking rule ensures that only one of the routes to the same destination is accepted. See RFC 4271 for more details on this tie-breaking rule.
Routes in the Loc-RIB are now placed into the local routing table. The true next hop address is taken from the local route entry to the IPv4 address specified in the NEXT_HOP attribute.
All routes in the Loc-RIB and all routes in the local routing table are eligible to be advertised to external peers of this router. Only routes in the Loc-RIB learned from external peers are eligible to be advertised to all internal peers of this router unless route reflection is enabled (see RFC 2796). The outbound policy disseminates the routes to a peer-specific Adj-RIB-Out. The outbound policy may perform route aggregation or path attribute modification. Changes in the Adj-RIB-Out cause the update process to send an update to the peer.
8.4.2. BGP Message Header
BGP messages are carried on top of TCP connections, which can be established over either IPv4 or IPv6. The source and destination IP addresses of the datagram depend on the peer configuration. They are always unicast. BGP connections use the well-known TCP port 179. Remember that only one TCP connection is established between two peering routes. Figure 8-37 shows the BGP message header format. The header has a fixed size of 19 bytes.
Figure 8-37. BGP message header format
The fields of the BGP header are explained in detail in the following list:
8.4.3. OPEN Message
As soon as the TCP connection between two BGP peers has been established, the routers send OPEN messages to initialize the BGP connection. This message verifies the validity of the peer and negotiates parameters used for the session using the fields illustrated in Figure 8-38. To verify the validity of a peer, each side of the connection must configure the IP address and the AS number of the peer.
Figure 8-38. The BGP OPEN message
The following list details of the fields of the OPEN message:
The authentication for BGP connection is currently mostly based on the MD5-signature-option and implemented directly in TCP. This authentication does not use the authentication data subfield.
The multiprotocol capability is used in conjuntion with IPv6. It has a 4-byte value field. The first 2 bytes identify the Address Family Identifier (AFI), byte 3 is reserved, and byte 4 defines the Subsequent Address Family Identifier (SAFI). AFI defines the network layer protocol used in the multiprotocol extension. SAFI defines additional information about the protocol, such as whether the protocol uses unicast forwarding (SAFI=1), multicast forwarding (SAFI=2), or both (SAFI=3). To support IPv6, the Multiprotocol Extension Capability is set to <Code=1, Length=4, Value=hexadecimal 0x0002 0001>.
8.4.4. UPDATE Message
An UPDATE message carries BGP route(s) advertised by the originating peer. It is divided into three sections, as outlined in Figure 8-39. The first section specifies the IPv4 NLRI that the sending peer is withdrawing. The second section defines all path attributes associated with the feasible IPv4 NLRI followed in section three. Multiple NLRI with the exact same set of path attributes can be placed in a single UPDATE message.
Figure 8-39. The BGP UPDATE message
The fields of the UPDATE message are detailed in the following list:
8.4.5. BGP Attributes
Path attributes provide additional information about the advertised NLRI. Each path attribute has a 2-byte attribute header, as depicted in Figure 8-40.
Figure 8-40. The BGP path attributes
The following list explains the Path Attribute in detail:
8.4.6. NOTIFICATION and KEEPALIVE Messages
NOTIFICATION messages are used to report errors. A 1-byte Error Code field specifies the main category of the error. A Subcode field providing the actual error follows the Error Code field. For troubleshooting reasons, additional data about the error is placed in the Data field. See RFC 4271 for all error codes. Additional documents extending BGP add error subcodes. Error messages for the BGP Extension for IPv6 are specified in RFC 2858.
KEEPALIVE messages contain no data whatsoever, just the BGP message header with the message type 4. They are used to prevent a BGP connection from timing out.
8.4.7. BGP Multiprotocol Extension for IPv6
BGP-4 carries only three pieces of information that are truly IPv4-specific:
To make BGP-4 available for other network layer protocols, the multiprotocol NLRI and its next hop information must be added. RFC 2858 extends BGP to support multiple network layer protocols. IPv6 is one of the protocols supported, as emphasized in a separate document (RFC 2545). To accommodate the new requirement for multiprotocol support, BGP-4 adds two new attributes to advertise and withdraw multiprotocol NLRI. The BGP Identifier stays unchanged. BGP-4 routers with IPv6 extensions therefore still need a local IPv4 address. To establish a BGP connection exchanging IPv6 prefixes, the peering routers need to advertise the optional parameter BGP capability to indicate IPv6 support. BGP connections and route selection remain unchanged. Each implementer needs to extend the RIB to accommodate IPv6 routes. Policies need to take IPv6 NLRI and next hop information into consideration for route selection.
An UPDATE message advertising only IPv6 NLRI sets the unfeasible route length field to 0 and carries no IPv4 NLRI. All advertised or withdrawn IPv6 routes are carried within the MP_REACH_NLRI and MP_UNREACH_NLRI. The UPDATE must carry the path attributes ORIGIN and AS_PATH; in IBGP connections it must also carry LOCAL_PREF. The NEXT_HOP attribute should not be carried. If the UPDATE message contains the NEXT_HOP attribute, the receiving peer must ignore it. All other attributes can be carried and are recognized.
An UPDATE message can advertise both IPv6 NLRI and IPv4 NLRI having the same path attributes. In this case, all fields can be used. For IPv6 NLRI, however, the NEXT_HOP attribute should be ignored. IPv4 and IPv6 NLRI are separated in the corresponding RIB.
188.8.131.52. MP_REACH_NLRI path attribute
This optional nontransitive attribute allows the exchange of feasible IPv6 NLRI to a peer, along with its next hop IPv6 address. The NLRI and the next hop are delivered in one attribute, as depicted in Figure 8-41.
Figure 8-41. The MP_REACH_NLRI path attribute for IPv6
The fields comprising the MP_REACH_NLRI path attribute are detailed in the following list:
184.108.40.206. MP_UNREACH_NLRI path attribute
This optional nontransitive attribute allows the sending peer to withdraw multiple IPv6 routes that are no longer valid. As illustrated in Figure 8-42, it basically contains a list of IPv6 prefixes that the peer should remove from its RIB.
Figure 8-42. The MP_UNREACH_NLRI path attribute for IPv6
The fields comprising the MP_UNREACH_NLRI path attribute are detailed in the following list: