IPv6, DDoS and Project Calico

There has been quite a bit of discussion recently about DDoS and IPv6.  While IPv6 networks share many (or most) of the same DDoS vulnerabilities as their IPv4 counterparts, there are (at least) two areas where IPv6 faces different DDoS challenges than IPv4.

One is that some diagnostic and mitigation tool packages are not IPv6 aware, or their IPv6 versions may not have feature parity with the longer-established IPv4 versions.  This is something that Project Calico can not address, but we expect that this will correct over time, as more organizations start deploying IPv6.

The other, however, is specific to IPv6 (or at least exacerbated by IPv6’s sparse address space).

The vacant address DDoS attack

A quick overview of what happens when a router receives a packet addressed to a destination that it is “authoritative” for, but doesn’t know about.

If a router is directly connected to an IP network, it is considered “authoritative” for that network, it doesn’t need to forward traffic addressed to that network to another router.  If a router receives a packet addressed to a network it is directly connected to, and the router knows the L2 address for that destination, it forwards the traffic to that L2 address and the matter is finished.  However, if the router does not know the L2 address of the destination, it broadcasts on the physical network asking for the L2 address that “handles” that destination IP address.  In IPv4, that broadcast is an ARP, in IPv6, it’s a “neighbor discovery” or ND.

So, a DDoS technique (that works on both IPv4 and IPv6) is to send traffic addressed to random addresses in a network, and hope that many of those addresses don’t actually exist, causing a broadcast storm on the physical network, and loading down the router that is having to send all of the ARPs or NDs.

The reason this is a larger problem in IPv6 than IPv4 is the relatively sparse address space in an IPv6 network.  If we take a classical “/24” IPv4 subnet that has, say 64 hosts on it, then there is a 25% (64/256) chance that a host actually exists at the address that is being used for the DDoS, so there is a limited amount of amplification that can happen.   Simply put, the IPv4 world is denser, and there is less free space.

Now, if we take that network of 64 hosts and put them in an IPv6 subnet (which, by default is a 64-bit address space), there are 1.85e+19 available addresses, meaning that there is, for all intents and purposes 0% chance that traffic addressed to a random address in that subnet will actually “hit” one of those 64 hosts.  This means that if an attacker “sprays” a target IPv6 network, effectively EVERY packet will lead to an ND broadcast (actually multicast, but the effect is the same).

How does Calico address the vacant address attack?

Because Calico, by default, announces every endpoint or host (in Calico terminology, an endpoint is a guest on the Calico network, so while host is the general term, we will use endpoint to match the terminology used in the rest of the Calico documentation) in the Calico network, and does so with it’s endpoint address (a route that only matches that specific endpoint), any router that is peered with a Calico network has, in it’s routing table a complete, and accurate list of endpoints on the Calico network.  This gives us the tool necessary to stop the vacant address attack.

Every router has the concept of a black hole route.  If I put a route into a router that is a black hole route, then any traffic that matches that route is silently discarded.

Another tool that every router has (or does) is what is called longest prefix match.  Basically, a router may have multiple routes that match a given destination, but only the most specific match is used.

We can combine these two to solve the IPv6 vacant address DDoS attack.  If a Calico network is using a given IPv6 block (say 2001:db8:dead::/48), every border router in the Calico network would install a black hole route that covers the entire block that is in use.  Since that border router would have more specific routes for each real endpoint in the Calico network, traffic addressed to a real endpoint in that IPv6 block (say 2001:db8:dead:beef::87/128) would be forwarded to the destination, but traffic addressed to an address where there isn’t a more specific (i.e. an address that isn’t in use in the Calico network) would be dropped by the black hole, thereby preventing the ND amplification.
Christopher Liljenstolpe

Christopher Liljenstolpe

Christopher is the original architect of Project Calico and one of the project's evangelists. In his day job, he's the director of solutions architecture at Metaswitch Networks. Prior to Calico/Metaswitch, he's designed and run some bio-informatics OpenStack clusters, done some SDN architecture work at Big Switch Networks, Run architecture at two large carriers (Telstra - AS1221, and Cable & Wireless/iMCI - AS3561) and been the IP CTO for Alcatel in Asia. He's also run networks in Antarctica (hint, bend radius becomes REALLY important at -50C), and been foolish enough to do a stint as a wg co-chair in the IETF. Occasionally you can have the (mis-)fortune of hearing him speak at conferences and the like.

You Might Also Like

What’s new in Calico 3.15

We’re very excited to announce Calico v3.15.0, which includes a bunch of great features including generally available Wireguard encryption, and the ability to migrate Calico’s data storage from etcd to

Read More

Join our mailing list​

Get updates on blog posts, new releases and more!

Thanks for signing up!