It’s been a while since Part 1 and Part 2 from the Back to Basics series so let’s complete it with a review of the final address type we’ll cover (and how it used in IPv6): anycast.
As a quick review, the goal of this “back to IPv6 basics” series is to provide a bit more detail on the three main address types in IPv6. They are:
- Unicast
- Multicast
- Anycast
Most network operators (Enterprise or Service Provider) who are providing highly-available and/or distributed services (like DNS or DHCP) are already leveraging anycast, with either IPv4 and/or IPv6. Anycast is a straight-forward concept but sometimes there are some implementation challenges that go hand-in-hand with routing protocols (around convergence). Because of this, it is useful to review how anycast can be leveraged. The great news is that anycast functions the same for IPv6 as for IPv4, making adopting and use of IPv6 anycast a breeze for anyone who has done it in IPv4 already.
Anycast is an odd address type because there is no obvious way to tell an anycast address from a unicast address. A unicast address is defined as a single unique address per network interface but an anycast address defines a group of network interfaces with the same shared address. With IPv6, because we can have multiple addresses per interface the anycast definition becomes even more convoluted. It may seem counter-intuitive and a violation of the address uniqueness requirements to have a single address used by multiple interfaces, but trust me, it works. Any address within the IPv6 Global Unicast Address (GUA) address ranges may be used as an anycast address.
Reachability to a given anycast address is handled by routing protocols. The multiple interfaces that are configured with the anycast address use a dynamic routing protocol like OSPF or BGP to advertise the /32 (for IPv4) and the /128 (for IPv6) host route. The usage goal of making the anycast address available to a resource from the “closest” routing location. The user of the anycast service communicates with the anycast address that is nearest. If any of the anycast nodes fails, then the route is withdrawn, the routing tables converge, and the users communicate with their new “nearest” anycast address. There is no functional implementation difference for anycast in IPv4 compared to IPv6.
There are a handful of Internet services that leverage anycast to make it easier to remember a specific service offering. Some of the more famous anycast addresses that people might know include:
8.8.8.8 – Google’s IPv4 public DNS server
8.8.4.4 – Google’s IPv4 public DNS server
2001:4860:4860::8888 – Google’s IPv6 public DNS server
2001:4860:4860::8844 – Google’s IPv6 public DNS server
207.171.17.0/24 – pool.ntp.org anycast range
2620:101:d007::/48 – IPv6 pool.ntp.org anycast range
1.1.1.1 – Cloudflare’s IPv4 public DNS server
1.0.0.1 – Cloudflare’s IPv4 public DNS server
2606:4700:4700::1111 – Cloudflare’s IPv6 public DNS server
2606:4700:4700::1001 – Cloudflare’s IPv6 public DNS server
It is most common to see DNS and NTP services using anycast for their public Internet presence but there are other services that might leverage anycast. The thirteen root name servers all use anycast addresses. Email, SIP gateways, websites, VPN gateways, and more specialized services may take advantage of anycast but you would have no idea they are doing it unless you spend some time doing packet analysis. And really, that is the point. You don’t need to know that a service is leveraging anycast, it should look and function like unicast as far as the consumer of the anycast service is aware.
So what structural advantage do operators get by setting up anycast? Really there are two. The first is simplification for consumers of a service in remembering the IPv4 or IPv6 address. This isn’t as much of a concern since DNS is such a fundamental service for the Internet. But at some point, a basic DNS resolver must be provided to a host. With DHCP you get that information automatically and at this point that is the same model for DHCPv6 and now for SLAAC with RFC 8016 (Mobility with Traversal Using Relays around NAT (TURN)). The second advantage is solving the high availability problem without having to modify every endpoint about where the service is running. This is the primary reason operators deploy and use anycast for both IPv4 and IPv6. So anycast helps meet high-availability design requirements in a very simple and scalable way.
In an enterprise network, anycast solves the high availability issue for DNS, DHCP and NTP and may be leveraged for more services than those core fundamental ones. Depending on the design, the anycast services might be geographically bound to help ensure isolation of services if needed. At other times, the design might be truly global and used to provide highly available services regardless of location in the network. The use cases vary depending on security or business needs but the nice thing is anycast isn’t the limiting factor in the design decision. The only limit is how many anycast networks you want to advertise in your network but with the limitation that the anycast network must meet the minimum smallest routable block (IPv4 or IPv6) that is accepted into the default free-zone.
So that is it, the brief look at IPv6 anycast. It is a super useful address type that is likely completely unknown to the majority of people using it. It quietly solves the high availability problem for lots of operators and is used by everyone on the Internet. So thank you anycast!
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now!
– Ed
Ed Horley (@ehorley) is CEO of HexaBuild.io, an IPv6 consulting and training company. Ed is Co-chair of the California IPv6 Task Force (CAv6TF) and authored the Apress Press book on Practical IPv6 for Windows Administrators. Follow HexaBuild on Twitter and LinkedIn.
