BGP has been extended to support multiple protocols. In the early days BGP was developed purely for the IPv4 internet in mind, and to carry just unicast IPv4 prefixes. But in the intervening years, the folks who've been using multicast have developed extensions to BGP so it can be used for a distribution of multicast prefixes. And with the development of IPv6 in 1995 and 1996 BGP was also extended to carry IPv6. Rather than the, I suppose, incremental addition of support for extra protocols, this was all refined and the resulting RFC4760 document defines how multiple protocols will be handled within BGP itself. So now BGP has been extended to carry routing information of protocols other than v4. So we've seen MPLS of course, and IPv6 as I mentioned, as well as multicast. All these can now be handled with ease within BGP itself. The exchange of these multiprotocol network layer reachability information is negotiated when the BGP session starts up. So if you look at the detail of a BGP neighbor being established, it will ask a series of questions with its immediate neighbor about which extensions are actually supported. And you can find these out, again it depends on your implementation. You can find out which of the various BGP extensions you and your neighbor will actually support, just from the CLI. RFC2545, that describes the use of BGP multiprotocol extensions for v6 inter-domain routing. So that's, in other words, how BGP can handle the distribution of v6 prefixes across the internet. Now to support multiple protocols, each one operates independently. So for example for IPv4, the IPv4 destinations are held in BGP's IPv4 RIB. IPv6 destinations are held in BGP's IPv6 RIB. And there is no interaction between these two RIBs at all. Each protocol can have its own policies. You can implement one policy for IPv4 and another policy for IPv6. It's most common on the internet today as we'll discuss throughout the series, for network operators to implement both the same policies for v4 and for v6. but should there be a need for us not to do that, we can have separate policies if we wish. And one thing that's very very important and a lot of people actually mistake is that, if you have a v4 destination, the next router to get to that destination must be basically of the same address family, so the same type of address, so for example if you have a v4 destination, the next router to get to that destination must be reachable over IPv4. And likewise for v6. If you have a v6 destination, the next router to get to that destination must be a reachable over IPv6. We're going to look at the "nexthop" attribute a little bit later on, and we can discuss this in a little bit more detail then. But this is actually a fundamentally important part, we cannot have a destination in one address family that's reachable through a neighboring router that's in a different address family. Now for supporting multiple protocols, most router implementations today will have v6 turned on by default, and make no real assumption about any particular neighbor. if you're still using Cisco IOS, the older versions of IOS, they assume that all BGP neighbors will be exchanging v4 unicast prefixes. Even if these neighbors have v6 addresses. So, if you're using IOS you'll need to remove that assumption as shown in the slides. If you don't do that it's not going to cause any problem, it's just going to make the configuration look very messy. You end up with a configuration that shows a lot of v6 neighbors appearing as though they have been set up to exchange v4 unicast prefixes. And well, this isn't actually happening, they appear in the configuration, it makes it more cluttered and generally it just makes troubleshooting, and fault diagnosis just that little bit harder. Probably the last thing you want when you're trying to deal with a network outage or some other network emergency that you need to fix pretty quickly. For operational simplicity, what we really want is for v4 neighbors to exchange v4 prefixes, and v6 neighbors to exchange v6 prefixes; and then we just don't have any dependency of one protocol on another.

Related Documents

Exercises

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon. 

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)

This is a human-readable summary of (and not a substitute for) the license. Disclaimer.
You are free to:

Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material
The licensor cannot revoke these freedoms as long as you follow the license terms.
Under the following terms:

Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
NonCommercial — You may not use the material for commercial purposes.
No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.