It’s no bluff that IPv6 has been standardized for nearly two decades (RFC 2460). There has been close to zero percent adoption up until about 3-4 years ago where you can see some of the early adopters are getting their feet wet; Google Statistic shows climb from 2% to 18% in the past three years, by analyzing it’s users’ request origin. IPv6 BGP route table size is also up to 39k, per cidr-report.org.
Although it may look a bit daunting at first, it is actually quite simple to get started. You can start off by contacting your ISP to see if they can provide IPv6 service on your circuit, in which they will usually provide you a several /64 (for transit and internal usage) or a larger range, depending on your size and business needs. If you prefer to have your own PI space, you can request a prefix through ARIN (or your regions RIR); generally from what I’ve seen, you can get anywhere from a /56 at a small business, to a /40 for a medium enterprise, to a /32 for a large enterprise or small ISP and even larger from there. If your ISP doesn’t support IPv6 and you would still like to play around with it, don’t fret, you can utilize an IPv6 broker such as Hurricane Electric
Once you are ready to peer with your provider or IPv6 broker, here is a simple guide on how to configure your side of the connection
1. First step would be to check if your device/license supports both IPv6 and BGP. For Cisco, you can check this using their Feature Navigator. For my example, I am using a Cisco 3560, which will need IP Services license to support it.
2. Configure your peering transit interface for IPv6. Usually this is provided by means of a /64 for strict transit usage. My example uses SVI:
3. After verifying L3 connectivity, let’s get started on the BGP configuration. First lets configure our inb/outb filters. For the sake of this example, let’s assume default in and two custom prefixes out. These “filters” will be prefix-lists, with route-maps configured for flexibility at the BGP config level.
- Inbound is easy enough; allow default
- Outbound is also simple, just specify YOUR prefixes, whether from your ISP or RIR
- And route-maps matching our configured prefix-lists; route-map allows for flexibility and should always be used
4. Once we are ready with our filters, we can get going with the actual BGP process configuration. First, enter the BGP router configuration and configure your peer ISP neighbor, but at this point, it will be disabled until your IPv6 family configuration exists. Second, enter the ‘address-family ipv6 unicast’ context and specify your networks to advertise and your neighbor activate/route-map commands as you see below. This should complete your basic IPv6 BGP configuration and we can move on to some verification
- If you haven’t done so already, make sure that your prefixes exist in the global RIB (‘
show ipv6 route’) in order for BGP to inject them into the BGP IPv6 RIB. The prefixes you specified in the BGP configuration will not be advertised if they don’t exist in the global RIB. If they are not, you can create a placeholder route for now, with the ‘ipv6 route’ command (Example:
ipv6 route 2001:db8:dddd::/56 Null0). Directing traffic towards Null0, essentially discards the traffic when it is processed by the routing engine. This is good if you plan to distribute your larger prefix into smaller /64 size subnets, because it will discard the traffic that doesn’t match a more specific route but this is a whole different topic to go on about =). For now, it will allow the route to be propagated into the BGP IPv6 RIB since Null0 is always reachable.
5. You can quickly verify IPv6 BGP neighbor status with ‘
show bgp ipv6 unicast summary’, which will list the neighbors and if your BGP state is ‘Established’, then you will not see a BGP state, but instead, a count of prefixes received from that specific neighbor:
- And you can verify received prefixes by checking the global and BGP IPv6 RIBs
You can see that the received route made it successfully into respective IPv6 RIBs, accompanied by the static routes created earlier for injection into BGP. The routes should propogate fairly quickly into the many looking glass servers available on the WWW today and can also be verified via traceroute (you can use a web tool such as http://ping.eu/traceroute if you do not have IPv6 client access).
After successfully deploying IPv6 at your edge network, there are several different options for moving IPv6 into your core infrastructure. You can go dual-stack from the edge to the server, which would be the most difficult. Another option would be to choose a IPv4/IPv6 segregation point in your network, to perform translations or act as an IPv6 proxy towards your IPv4 servers. If your a hosting or cloud service provider, the ladder seems to be the best option as it provides an easy migration path from IPv4 to IPv6 on the application side, if done right; you can support IPv6 to your load balancer, proxying traffic to your IPv4 servers, with the option to add your IPv6 servers to the LB pool once you are ready and migrate to them seamlessly.
Hope this helped as a primer and to give you a basic path for moving towards IPv6 at the network infrastructure level (or just to test it at the very least).
Feel free to ask any questions or drop a comment!