In recent years, the concepts of Artificial Intelligence (AI) and Machine Learning (ML)...
IPv4 BGP vs IPv6 BGP
A little magic is required to let a 21-year-old routing protocol carry routing information for a 19-year-old network protocol: that would be the Multiprotocol Extensions. These turn regular BGP-4 into Multiprotocol BGP (MP-BGP), although that term is rarely used these days. The Multiprotocol Extensions, originally published as RFC 2283 in 1998, use some clever encoding to allow BGP-4 to carry a wide range of “address families”.
Usually, an address family identifies a network protocol, but there are also AFI (address family identifier) numbers given out for phone numbers and DNS names, which don’t map directly to a network protocol. In addition to the AFI, MP-BGP also uses a Subsequent Address Family Identifier (SAFI), which indicates the use of regular unicast routing, multicast routing, distributing VPN information, and so on. For instance, AFI 1 with SAFI 2 means BGP will carry IPv4 multicast routing information, and AFI 2 with SAFI 1 specifies IPv6 unicast routing information.
BGP routers that support IPv6 allow BGP sessions to be set up using IPv6 addresses. MP-BGP speakers tell their neighbors which AFI+SAFI combinations they want to use in the OPEN message at the beginning of a BGP session. This can lead to the situation where IPv6 routing information is exchanged over IPv4, or IPv4 routing information is exchanged over IPv6. In principle, there’s nothing wrong with that, but it does lead to a complication: how does the router know what IPv6 next hop address to include in its updates towards an IPv4 neighbor? To avoid this situation, it’s considered best practice to only exchange IPv4 prefixes over an IPv4 external BGP (EBGP) session and only exchange IPv6 prefixes over an IPv6 EBGP session.
However, internal BGP (IBGP) doesn’t update the next hop address, so there are no problems exchanging both IPv4 and IPv6 prefixes over the same IBGP session. So most networks use the existing IPv4 IBGP sessions to exchange IPv6 prefixes rather than set up a whole new set of IPv6 IBGP sessions. The only downside of this approach is that if then something bad happens to IPv4, the IPv4 IBGP sessions go down and IPv6 is also affected. If IPv6 had its own IBGP sessions, it may have continued to operate independently from IPv4.
All this comingling of IPv4 and IPv6 within BGP does make configuring a router a bit more complex. This is what a simple BGP configuration on a Cisco router looks like in an IPv4-only world:
router bgp 64512
network 172.16.0.0 mask 255.240.0.0
neighbor 192.0.2.2 remote-as 65500
neighbor 192.0.2.2 description My favorite BGP neighbor
neighbor 192.0.2.2 prefix-list outfilter out
neighbor 192.0.2.2 filter-list 1 out
!
ip as-path access-list 1 permit ^(64512_)*$
ip prefix-list outfilter permit 172.16.0.0/12
!
A BGP configuration that does the same thing for IPv6 looks like this:
router bgp 64512
neighbor 2001:db8:c0f:fee::6:5500 remote-as 65500
neighbor 2001:db8:c0f:fee::6:5500 description My favorite BGP neighbor
!
address-family ipv6 unicast
neighbor 2001:db8:c0f:fee::6:5500 activate
neighbor 2001:db8:c0f:fee::6:5500 prefix-list outfilter out
neighbor 2001:db8:c0f:fee::6:5500 filter-list 1 out
network 3ffe::/16
!
ip as-path access-list 1 permit ^(64512_)*$
ipv6 prefix-list outfilter permit 3ffe::/16
!
So the settings that are the same for both IPv4 and IPv6 (most notably the remote AS number, but also the description) are configured immediately following the “router bgp …” line, but anything IPv6-specific is grouped under “address-family ipv6”. (Or “address-family ipv6 unicast”.) Obviously, the IPv6 prefixlist goes under the IPv6 settings, but the same applies to the IP AS path access list: you may want to apply different AS path filters to IPv4 and IPv6. Things get interesting when we merge both configurations. If we then display the router configuration, it will look something like this:
router bgp 64512
neighbor 2001:DB8:C0F:FEE::6:5500 remote-as 65500
neighbor 2001:DB8:C0F:FEE::6:5500 description My favorite BGP neighbor
neighbor 192.0.2.2 remote-as 65500
neighbor 192.0.2.2 description My favorite BGP neighbor
!
address-family ipv6
neighbor 2001:DB8:C0F:FEE::6:5500 activate
neighbor 2001:DB8:C0F:FEE::6:5500 prefix-list outfilter out
neighbor 2001:DB8:C0F:FEE::6:5500 filter-list 1 out
network 3FFE::/16
exit-address-family
!
address-family ipv4
no neighbor 2001:DB8:C0F:FEE::6:5500 activate
neighbor 192.0.2.2 activate
neighbor 192.0.2.2 prefix-list outfilter out
neighbor 192.0.2.2 filter-list 1 out
network 172.16.0.0 mask 255.240.0.0
exit-address-family
!
So what has happened is that the router decided that now that we’re using an IPv6 address family, we need to be more specific about our IPv4, too, and moved all the IPv4-specific configuration commands to a new “address-family ipv4” section.
Also note how neighbors are deactivated for IPv4 and activated for IPv6, as exchanging IPv4 prefixes and not exchanging IPv6 prefixes are the default behavior—even for BGP sessions towards an IPv6 neighbor. However, these defaults may not be universal across software versions and different BGP implementations that use Cisco-like configuration commands, so it’s best to always explicitly activate and deactivate all IP version combinations, with the exception of activating IPv4 for IPv4.
Old Cisco IOS versions curiously used show bgp <command> for IPv6 wherever show ip bgp <command> was used for IPv4. Later this was changed to show bgp ipv6 <command> and after that to show bgp ipv6 unicast <command>. (And show ipv4 unicast <command> can be used for IPv4.)
The minimum prefix size that you’ll see in IPv6 is /48, which is the size of provider independent address blocks. ISPs get at least a /32. The IPv6 routing table is much smaller at some 21,000 prefixes while the IPv4 global routing table is well over half a million prefixes. But with the above in mind, there’s really no fundamental difference between how BGP works for IPv4 and IPv6. IPv6 is still IP, after all.
Boost BGP Performance
Automate BGP Routing optimization with Noction IRP
SUBSCRIBE TO NEWSLETTER
You May Also Like
When Critical Infrastructure is Vulnerable: Rethinking Network Resilience
Recent disruptions to two undersea internet cables in the Baltic Sea have yet again highlighted a pressing issue for...
From Idle to Established: BGP states, BGP ports and TCP interactions
Understanding BGP states is essential to grasp how BGP operates. Similar to interior gateway protocols (IGPs) like...
ACK and NACK in Networking
In networking, communication between devices relies on the efficient exchange of data packets. Among the essential...