RIPE Atlas - A Case Study of IPv6 /48 Filtering

In IPv4, a /24 network is commonly seen as the longest prefix that won't be filtered in BGP but there is no clear consensus like this for IPv6. The most recent debate I have seen on this subject was on the ipv6-ops mailing list , and two cases of /48 IPv6 prefixes that could be subject to strict filtering were mentioned there; one for Cloudflare, the other one for German broadcaster RTL. A summary of the debate is that a /32 prefix announced to enough relevant networks should be pretty much globally visible but longer prefixes are not guaranteed to be visible due to BGP filtering, specifically if longer prefixes are announced out of IPv6 allocated space, without a covering prefix.

The best resource on IPv6 filtering I'm aware of is Gert Doerings , which has some recommendations on relaxed and strict filtering. From this page:

 The goal of BGP prefix filtering is to contain the mistakes to the
AS where they originate, and not distribute them all around the world.

In the strict filtering case, only routes matching the allocation sizes that the registries hand out are permitted. As is already mentioned about strict filtering recommendations on this page:

 
  Never assume that these filtering examples are the last word regarding filters. THEY CAN BE OUTDATED
 

A frequently heard adage with regards to how to announce IPv6 prefixes is "my network, my rules". There is no "network police", and an aggregate of all networks that make up the Internet will decide whether IPv6 prefixes of certain sizes are accepted by the Internet. This article contains some data on what we currently see in RIPE Atlas on the data plane regarding this issue.

Results

With RIPE Atlas we allow for IPv6 traceroutes from all 600+ IPv6 enabled RIPE Atlas probes to a single destination , which is currently a RIPE NCC member only service. I used this service to traceroute6 from IPv6 enabled RIPE Atlas probes to www.rtl.de , imgur.com (which is in the CloudFlare /48 that is mentioned in the ipv6-ops thread) and ns.ripe.net , which is in a /48 IPv6 PI-block. As a reference I used traceroute6 to google.com.

Case 1: google.com (baseline)

As a baseline I took traceroute6s from RIPE Atlas probes to google.com . Google is a network that has done extensive work to ensure that they are reachable over IPv6. Our probes resolved this hostname to 274(!) IPv6 addresses, all of which had at least a covering /32 IPv6 prefix as seen in the RIPE NCC's Routing Information Service (RIS). A visual representation of the result for all traceroute6s for this case is available here.

Case 2: ns.ripe.net (/48-PI, no covering prefix)

n s.ripe.net is a case of a destination that is in a /48 IPv6 PI prefix. We didn't see any covering/shorter prefixes in RIS, so this should serve as a baseline for reachability of /48 PI prefixes. A visual representation of the result for all traceroute6s for this case is available here .

Case 3: imgur.com (/48-PA, with covering rir prefix)

imgur.com resolves to two IPv6 addresses that are in the same /64. This network is part of an APNIC /32 allocation to Cloudflare, but is announced as a /48 with no covering IPv6 prefixes from the same origin AS. Incidentally, this prefix is covered by 2400::/12 that is used for Geoff Huston's IPv6 darknet experiment . This /12 is announced from a different origin AS of course, but could influence reachability: In networks that filter this /48, the /12 could cause packets to be routed towards the origin of the /12 announcement and as soon as packets enter a network that doesn't filter the /48, packets will be routed towards the origin of this /48. So even if a networks BGP-filters the /48 prefix, the /12 could cause packets originating from this network to still reach the destination /48. In networks with strict IPv6 filters both the /48 and the /12 could also be filtered of course. A visual representation of the result for all traceroute6s for this case is available here.

Case 4: www.rtl.de (/48-PA-no-covering-prefix)

This case is similar to case three, but it doesn't have a covering prefix (not from the same origin AS, nor from another AS). Because I didn't have a destination in this network that responds to UDP-traceroute6, I had to resort to ICMP-traceroute6, ie. the traceroute6 probe packets were ICMP packets, instead of the common default UDP. A visual representation of the result for all traceroutes for this case is available here.

Comparison of results for different cases of announcing IPv6 prefixes in BGP

Table 1: Results from traceroute6 to the 4 cases described above. The numbers in individual cells of this table represent the number of RIPE Atlas probes that fall into each category.

Table 1 shows the results of traceroute6 to the four cases described above. This only includes the Atlas probes that were seen in all four experiments, and provided traceroute6 results beyond hop 2. This filtering brings the total number of probes that we report results from down from roughly 600 to roughly 500. The 'Destination Reached' column shows how many probes succeeded in reaching the destination, while the 'Destination Not Reached' column shows how many probes failed to reach the intended traceroute6 destination. The next three columns provide a break down of this latter class. Probes with traceroute6 results that, on the last hop, don't have a responding hop are in the 'last hop has no IP address'-category. These are traces where no responses were seen beyond a certain point, which could be due to silent discarding of response packets (ie. blackhole). A traceroute6 representative of this case:

 Traceroute from Probe XXX  to 2001:67c:e0::6  (Mon Jul 23 15:22:01 2012 UTC)
  1 2a02:500:4400:XXXX::XXXX     1.792 1.936 8.495
  2 2a02:500:3330:100::5         2.306 2.358 2.626
  3 2001:798:21:10aa::1          3.016 3.032 7.849
  4 2001:798:cc:2101:2101::6     2.944 2.948 3.12
  5 * * *
  6 * * *
  7 * * *
  8 * * *
  9 * * *
255 * * *

Probes with a 'Network Unreachable' ICMP6 response on the last hop of traceroute6 results ( !N in traceroute6-output) are listed in the 'Network Unreachable'-category. This is a tell-tale sign of BGP prefix filtering.

As can be seen from this table, we have some 3% of probes that, even in the baseline measurement, don't reach the destination. A large part of this is likely due to probes that are set up in experimental IPv6 networks, and in the future we could potentially improve this by using an alerting mechanism to make probe hosts aware of problems with their IPv6 network connectivity. The results in this article are already filtered for traceroute6 results that don't go beyond hop 2, which should catch problems at customer premise equipment (CPE) and broken tunnels connected to CPE. This filtering doesn't seem sufficient to catch all of the experimental IPv6 setups where RIPE Atlas probes are deployed.

Table 1 also shows that there is hardly any difference between the baseline and the /48 PI block with no covering prefix. The interesting case is the /48 prefix out of a PA block with covering prefix, as that shows five probes (roughly 1% of the total number of probes) where traces end up with a 'network unreachable', a tell-tale sign of BGP prefix filtering, whereas the baseline and /48 PI case don't have any 'network unreachable' traces. The /48-out-of-PA block with no covering prefix shows the same amount of 'network unreachable' problems but has less traceroute6-blackholes. The reduced number of traceroute6-blackholes could be due to the fact that ICMP-traceroute instead of UDP-traceroute was used for that experiment. Four probes produced traceroute6 results that had 'network unreachable' for both of the /48-out-of-PA cases (i.e. case 3 and 4).

Based on this data I'd say that strict IPv6 prefix filtering does matter, but currently only a little bit.

The data that is presented here reflects prefix filtering seen between the network of IPv6 enabled RIPE Atlas probes and the 4 cases presented above. It is unknown how representative this is for the global IPv6 Internet. But we can quantify this a bit: We have probes in roughly 300 ASes out of the 5770 ASes that are announcing IPv6 address space (per 2012-07-01), and typically see around 400 ASes in the traceroute paths towards responding destinations. RIPE Atlas probes are most densely deployed in the RIPE NCC service region. Of course you can help bring more AS-diversity to the RIPE Atlas network, by applying for a probe and put it in a network where we don't have coverage yet!

I hope this sheds some light on the current state of IPv6 prefix filtering.