In its most basic form, a tunnel broker service provides a network tunnel delivering encapsulated connectivity over existing infrastructure. Of course, based on such a general definition, even a VPN provider could be considered a tunnel broker. However, the meaning of this term is somewhat more specific; it most commonly describes a service delivered by a tunnel broker to carry IPv6 traffic over IPv4 infrastructure, as described in RFC 3053. Such services are typically used to provide IPv6 connectivity to a network that exists in a region of the internet that supports only IPv4.
Now, where does BGP come into all of this? Well, if you have your own range of public IPv6 addresses that you want to advertise to the internet at large, and you reach the IPv6 internet via a tunnel broker, you’ll need to announce those addresses using BGP over that tunnel broker service.
Different people will use different terms to refer to these related services. “BGP tunneling,” “tunnel broker BGP,” “IPv6 tunnel broker,” and “6in4 tunnel” are just some permutations of these terms. In general, they refer to the provisioning of BGP to advertise IPv6 prefixes over a tunnel broker service, where IPv6 traffic is tunneled over an IPv4 infrastructure.
Introduction
In this article, we take an approach from first principles, ensuring that all aspects are covered from the ground up to provide a clear picture of what is necessary for BGP to function over a tunnel broker service.
- First, we look at what a tunnel broker service is, how it operates, and why it is important in today’s internet environment
- Next, we focus on how BGP announces IPv6 addresses on the internet in general.
- Finally, we examine the functionality and features of BGP-enabled tunnel broker services and discuss some best practices to keep in mind.
Explanations
Tunnel Broker Service Primer
The following is some background information that will help us get a firmer understanding of what a tunnel broker service is, and how it is related to BGP.
The Current State of the Internet
The internet is currently going through a significant transformation, arguably the most significant since its inception decades ago. On June 6, 2011, a date chosen by the Internet Society, the official transition of the internet to IPv6 began. As of mid-2022, almost 11 years later, only 40% of the world’s internet users use IPv6 natively to connect to the internet, according to Google. This means that a significant portion of the internet is still using IPv4 infrastructure, and it is expected to do so for the foreseeable future.
Why is it taking so long? Well, there are several factors affecting the rate of adoption, including the following:
- Extensive use of NAT both by customers and within the internet itself (using carrier-grade NAT) has partially resolved many of the IPv4 address exhaustion problems.
- IPv6 adoption involves extensive network restructuring and time-consuming personnel training, and can be expensive, so many providers are delaying it as long as possible.
- Many innovative mechanisms have been implemented to allow IPv4 and IPv6 to coexist relatively seamlessly.
We won’t go into the details of these reasons—and there are many more—but we will mention that tunnel brokering services are one of the innovative services that allow IPv4 and IPv6 to coexist and are lengthening the migration timeline worldwide.
Different areas of the world are adopting IPv6 at different rates, so we see some countries reaching close to 70% adoption, while a significant number of others are still at less than 10%.
Why Are Tunnel Brokering Services needed?
Let’s examine a hypothetical part of the internet:
Here we have an enterprise that hosts a web server with a native IPv6 address. This enterprise connects to the Internet via the ISP router, but the portion of the internet at this particular location uses only IPv4 infrastructure. To deliver native IPv6 service to the enterprise, the ISP creates what is known as an IPv6 in IPv4 tunnel, also referred to as a protocol 41 tunnel or 6in4. These are tunnels where IPv6 is tunneled directly inside IPv4 packets by having the protocol field set to 41 in the IPv4 packet.
The following displays the various fields found in the header of an IPv4 packet, with the 8-bit Protocol field highlighted. That field indicates what protocol is being encapsulated within the IP packet. Under normal circumstances, it would have a value such as 6 for TCP or 17 for UDP. But when tunneling IPv6, it uses a value of 41, which is used for IPv6 tunneling within an IPv4 packet.
{{banner-14="/design/banners"}}
Here is a Wireshark capture of such a tunneled packet, indicating the IPv4 header, the IPv6 header, as well as the protocol value of 41:
From the point of view of the enterprise, it has a web server with an IPv6 address that can be reached natively from any other IPv6 hosts on the internet at large, even though the enterprise is located somewhere where IPv6 is not capable of being directly provided.
Indeed, in this scenario, the enterprise is not taking part at all in the tunneling, a service that is provided solely by the ISP or some other entity in cooperation with the ISP. The tunneling mechanisms occur “behind” the ISP. So from the enterprise’s perspective, it doesn’t see any tunneling configurations.
Who Does the Tunnel Brokering?
A question that often comes up is: Where is the tunnel brokering done? Is it a black box for the enterprise, where none of the actual services are configured on the enterprise network? Or is it something that can terminate at the customer’s premises as well?
The diagram shown above shows a “black-box” scenario, where the tunnel brokering is taken care of completely by the ISP or another entity in cooperation with the ISP. However, there are services that actually terminate the tunnel at the customer edge equipment.
Take a look at the following diagram:
Here you can see that the tunnel terminates at the enterprise on-premises equipment. This is done in cases where there is no native IPv6 service even by any of the local ISPs themselves. This involves additional configurations that may need to be completed by enterprise technicians in association with the tunnel broker provider. Note here that the IPv4 domain extends to the enterprise edge device, meaning that its externally facing interface has a public IPv4 address, while its internally facing interface has an IPv6 address.
In such cases, the tunnel broker is most often independent of the ISP, and any BGP configurations involved are negotiated directly with the tunnel broker, apart from the ISP. However, before we move to see how BGP is involved in such scenarios, let’s first take a look at how BGP advertises IPv6 prefixes in general.
{{banner-15="/design/banners"}}
BGP and IPv6
The latest version of BGP, known as BGP-4, is defined in RFC4271, and its support for IPv6 is described in RFC 4760. The latter RFC actually describes support for multiprotocol extensions that include IPv6. This is achieved using the Address Family Identifier field that identifies the protocol being implemented. This, in conjunction with the Length of Next Hop Network Address field, which specifies the length of the next-hop address (32 bits for IPv4 or 128 bits for IPv6), allows BGP to be used for IPv6 addresses as well. This includes both creating BGP peerings using IPv6 addresses as well as advertising IPv6 prefixes.
These fields are actually part of a couple of additional BGP attributes known as MP_REACH_NLRI and MP_UNREACH_NLRI. These are optional and non-transitive attributes, so if a BGP speaker does not support multiprotocol extensions, they are ignored, and not forwarded. These details are further described in the RFCs mentioned above.
Unlike routing protocols that have different versions to support IPv4 and IPv6, such as OSPF and RIP, BGP-4 natively supports both versions of IP.
Advertising Public IPv6 Addresses Using BGP
Advertising any addresses on the internet requires a device operating as a BGP peer. This BGP peer must create an adjacency with other BGP devices either within the ISP or on the Internet. Such peerings are necessary to allow BGP to share and advertise the desired addresses.
Typically, the ISP’s on-premises router can play the role of the BGP peer advertising the enterprise’s address ranges, or the customer edge device can play that role. It all depends on the contract agreed upon between the customer and the ISP. This agreement becomes all the more important whenever tunnel brokers are involved because the BGP peerings must be created over the established tunnels. Where BGP is configured and where the tunnel broker’s service terminates can make or break the operation of BGP.
{{banner-7="/design/banners"}}
BGP and Tunnel Brokers
If you have services running on devices with public IPv6 addresses, you need to advertise those prefixes to the world so that the world can reach them from anywhere. If connected to the internet via an IPv6 tunnel broker, you must keep in mind that tunnel brokers do not create BGP peerings automatically nor do they forward BGP messages by default. Thus, you will need to ensure that your IPv6 addresses are being successfully advertised.
Where Does BGP Come In?
For the webserver to be reachable by online users, its IPv6 address must be advertised and proliferated throughout the internet. How this is done in a tunnel broker environment will also depend on the type of tunnel brokering that has been employed. Specifically, it has to do with where the tunnel is terminated: off-premises behind the ISP or on-premises at the customer equipment.
BGP with Off-Premises Tunnel Termination
Off-premises tunnel termination is typically a service delivered by ISPs for ISPs; it is not made available to the end-user but leveraged as a carrier-grade service. Let’s take a look at our diagram once again, but this time, assume that there is a BGP peering between the enterprise edge and a BGP peer on the internet:
The important thing here is to ensure that the tunnel broker being used by the ISP will successfully tunnel BGP messages without modification and without having them blocked. In most cases, the tunnel broker has its own BGP peering service, so that peer will actually belong to the tunnel broker itself. It is vital to ensure that such connectivity and operation is available from the tunnel broker service before embarking on such a network design.
BGP with On-Premises Tunnel Termination
On-premises tunnel termination services are typically provided to end-users as subscription-based services. Let’s take a look at our diagram in an on-premises termination scenario, again assuming there is a BGP peering in place:
Here you can see that the tunnel broker endpoint and the BGP peer on the side of the enterprise are at the enterprise edge device. Similarly, the BGP peer is at the tunnel broker’s endpoint that terminates the tunnel on the other end. In such a scenario, BGP is closely related to the tunnel broker services delivered by the provider. Once again, you must ensure that the tunnel broker delivers the BGP advertising service you require to support the advertising of your IPv6 addresses.
Best Practices and Other Considerations
There are several brokers that offer tunnel broker services, and most of these can be used to terminate on-premises tunnels. They deliver a wide variety of service levels, from free services to carrier-grade, high-availability services. Needless to say, free services are typically best-effort, while paid services incorporate some type of service level agreement. Important considerations to keep in mind as you choose your provider include the following.
Location of Points of Presence
Brokers will have Points of Presence in various locations in the world. To minimize latency, it is important to choose a location that is physically close to your enterprise.
Tunneling Protocols
The most commonly used protocol for encapsulation is the 6in4 protocol, as described at the beginning of this article. However, there are other choices that can be used, including Tunnel Setup Protocol (TSP), Anything In Anything (AYIYA) , OpenVPN, and WireGuard. Nevertheless, 6in4 is the most often used, as it is defined by the Internet Engineering Task Force in RFC 4213.
BGP Support
Not all tunnel brokers support BGP advertising of IPv6 in a tunneling environment. Some brokers offer BGP services at an additional cost.
Reliability
Some brokers have operated as a free or nonprofit service and ended up closing down due to insufficient funds. Be sure that the broker has a good track record and will be around for a long time to avoid the frustration of having to find a new one.
Additional Features and Other Considerations
Here are some other features that may be important when choosing a broker:
- IPv6 multicast support over the tunnel
- Reverse DNS (RDNS) delegations for the address space provided over the tunnel
- Configuration methods supported, which may include scripts, manual configuration, or configuration via a web portal or interface
In addition, it’s important to determine whether the tunnel broker is able to advertise the subnet you own or if you must obtain IPv6 addresses within the broker’s available IPv6 address space.
{{banner-sre="/design/banners"}}
Conclusion
As you can see, the world of tunnel brokers can be a precarious one if care is not taken when determining which services you need and comparing them to what is offered by particular providers. For this reason, it is important to:
- Determine the network design that will be implemented to advertise the IPv6 address space you desire.
- Settle on the BGP peering required, including the prefix ranges and the options delivered by the broker.
- Ensure that the broker will live up to what you require as far as the advertising of your IPv6 advertisements goes.
As long as IPv4 is still a major part of the internet, tunnel brokers will continue to be a service that is needed for those enterprises and users that require IPv6 connectivity within regions that only support IPv4 infrastructure.
