If we split Internet packets into good and bad packets, many of these bad packets can be filtered out already. For instance, for packets that come from address space that is not in use yet, network operators can create filters on their routers. These so-called bogon-filters need to be updated if new ranges of address space begin to get used. An example of this type of filtering can be found here, but a problem with relying on example filters like this is that they can become outdated, which means operators have to actively check if updates are needed.

In the past, when there was still IPv4 address space in the free pool, and the RIPE NCC got a /8 block of IPv4 address space from IANA, we debogonised it. What does that mean? By way of testing the usability of this range we announced parts of the address space to the Internet (typically a /24). That way we could see in BGP (the Internet's control plane) if this address space propagated. Also, with platforms like RIPE Atlas we could actually test if the data plane worked towards this new address space.

We have tested this type of filtering before - the debogonisation of 1.0.0.0/8 revealed a lot of inbound traffic to 1.1.1.0/24 for instance. And testing is not limited to large address blocks that the Regional Internet Registries start allocation and assigning from - we also did this for 128.0/16 as well as a number of very small IPv4 prefixes.

Now, in preparation to start allocating from 2a10::/12, we've been working to debogonise this block of IPv6 addresses. The tests we performed have focused on three main points:

1. Testing whether 2a10::/12 actually attracts traffic

2. Looking at the debogon prefixes in routing (using RIS)

3. Carrying out connectivity tests (with RIPE Atlas)

1. Does 2a10::/12 Attract Traffic?

To investigate traffic to this prefix, we announced the full 2a10::/12 from the RIPE Routing Information Service (RIS), using RRC03, the goal being to determine whether there are pieces of this address space that receive unexpected traffic. As this is previously unannounced address space, we had no expectation on what we would find. A /12 has 8.3 billion trillion trillion IPv6 addresses that could be targeted (0.024% of the full IPv6 space), an address range so vast that we cannot expect similar patterns to what has been previously studied in the IPv4 space. Unexpected traffic has a variety of sources, such as botnets targeting advertised space, network scanners, misconfigured devices, and so forth, each of which might send traffic into this new /12.

We captured all packets sent into 2a10::/12 from 13 January at 09:24:07 to 16 January at 09:52:07. In this timeframe, we counted 19,502,865 packets. Although this isn't a high volume of traffic, the space is certainly attracting much more than no traffic at all. What we see is this:

Figure 1: Traffic volume into 2a10::/12

The Busy Periods

In Figure 1 above, we see four busier periods: two with a lot of TCP traffic; two with a lot of ICMP traffic. The busy ICMP periods are easy to interpret, as they result primarily from RIPE Atlas measurements that we set up, which we'll cover later in this article.

The busier periods with TCP traffic are not caused by us, however. All this traffic originates from two IP addresses, seemingly in two different networks if the source addresses on the packets are to be believed:

• 2a05:e740:162::2 (RIPEstat link)
• 2605:fe00:0:17::1 (RIPEstat link)

All of these captured packets are TCP segments with only the SYN flag set and no payload. The source destination is always port 49152, and the destination is always port 80. Port 49152 is significant because it is the first port number in the dynamic range.

Both of the IP addresses above cycle through various destination IPs for its TCP SYN sweeps. From 2a05:e740:162::2, each IP targeted is targeted 20 times within 800ms, while from 2605:fe00:0:17::1, each IP address is targeted 11 times within about 450ms.

In the first busy period, both source IP addresses are active. The scanners are coordinated so that they target the same IP addresses, meaning that a connection is attempted to each destination address inside 2a10::/12 a total of 31 times. In the second busy period, only 2605:fe00:0:17::1 is active, so each destination address is targeted a total of 11 times.

In total, these two sources generate 5,485,022 (28.1%) of all the packets we observed. In this time, they attempt to reach 262,157 distinct addresses. The targeted addresses appear to be pseudo-randomly generated, and no /64 is targeted twice. It's unclear what the goal of these scans is - recall that in a /12 there are 2^48 such /64s, or over 281 trillion networks!

The Remainder / The Actual Noise?

Let's remove the traffic from those two IP addresses and from the RIPE Atlas probes, and take a look at what's left. Once we take away the two busy IP addresses generating TCP SYN traffic, and the RIPE Atlas ICMP echo request traffic (13,809,863 packets, or 70.8% of the total), we're left with only 207,980 packets (1.1% of the total). That remaining traffic looks like this:

Figure 2: Remainder traffic volume into 2a10::/12

In these packets, about 60% are TCP traffic targeting ports 443 and 80 (from a wide range of sources), and port 6379 (redis, mostly from one source IP). There is much more flag activity in general in these remaining packets, with random flag selections set. 26% are UDP packets, primarily targeting ports 53 (DNS) and port 443 (presumably QUIC). 13% are ICMP packets, mostly ICMP echo requests. Some of these are clearly not legitimate traffic, for example, ICMP echo replies, and many have invalid parameter numbers.

From the above, it's clear that there is some scanning behaviour. This should not come as a surprise: the moment the address space is visible in BGP, it can be picked up for use by anybody. But what's also clear is that traffic to this prefix is very low. Further, we looked for particular IP addresses or blocks that attracted an unusual volume of traffic, but we didn't find any.

Finally, there is a notable uptick in ICMP traffic soon after 08:07 UTC on 16 January, when we sent our announcement about the pingable targets to the routing-wg, mat-wg, and NANOG mailing lists.

Based on this, we're confident 2a10::/12 is ready for use with regards to not attracting spurious amounts of traffic in any part of the address range.

2. Do Allocations from this Address Block Propagate in BGP?

In addition to the test above, we started announcing a couple of /32 and /48 IPv6 prefixes on 15 January. We announced these prefixes from RIS's RRC03 which is connected to AMS-IX and NL-IX. See the table below for the differences between these prefixes, in terms of them having corresponding route objects in the RIPE Internet Routing Registry and/or having corresponding Route Origin Authorisations (ROAs):

The figures below show how many RIS peers saw these prefixes around the time we announced them, as compared to a baseline stable prefix we've been announcing from RIS for a long time already (brown line).

Figure 3: Visibility of debogon prefixes relative to a baseline prefix (brown line)

The lines for the different debogon prefixes are very close together and only a little below the brown line representing the base measurement. This means some of the RIS peers do not see the new prefixes out of 2a10::/12 yet. When we zoom in a bit more (see Figure 4 below), we find the /48s have slightly lower visibility than the /32s. Also the prefixes for which route objects exist have identical visibility regardless of their ROA status - in the graph, the line for 2a10:6::/32 is thus masked by the line for 2a10:4::/32; similarly, the line for 2a10:3:6::/48 is hidden behind the one for 2a10:3:4::/48.

Figure 4: Visibility of debogon prefixes relative to an anchor prefix (brown line), zoomed in

Upon comparing the older stable prefix to one of the new prefixes we found that seven of the RIS peers that provide us with a full routing table do not carry the debogon route. These peers represent four Autonomous Systems. We reached out to those organisations to figure out what causes the discrepancy. The responses we got indicated that strict prefix filtering was the cause, so work is underway to get that resolved.

Regardless, the results are in the margin of error and as expected if you look at earlier debogon efforts. This makes us confident that while we see less visibility than with an older control prefix, it will not cause major operational issues to the organisations that will receive allocations out of 2a10::/12 .

3. What Do we See with RIPE Atlas?

To learn how addresses in the debogon prefixes are reachable from different parts of the world, we set up ping measurements from all RIPE Atlas probes with working IPv6 connections. All the debogon prefixes have a pingable address at ::1 in the prefix. We sent an email out about this on the morning of 16 January, where we invited network operators to test reachability of these prefixes outside of our analysis using RIPE Atlas. Accounting for the possibility of packet loss, we grouped results in hourly bins, and have considered an address reachable when at least five out of an expected eighteen pings return an answer. Figures 5 and 6 show the results, with the second one zooming in on the first.

 Figure 5: Data plane reachability of pingable addresses in debogon prefix and anchor prefix

 Figure 6: Data plane reachability of pingable addresses in debogon prefix and anchor prefix (zoomed in)

The results for all addresses in prefixes with either ROA or Route object are virtually the same. And they are just a few percent below the control measurement towards the address in the RIS baseline prefix. That again gives us confidence that the 2a10::/12 address space can be used without problems.

On the morning of 16 January, the addresses for which the covering prefixes have route objects got a slightly better response compared to the ones that only have a ROA. The difference is, however, much smaller when compared to addresses for which neither a route object nor a ROA exist. Be it from a /32 or a /48 prefix, reachability from RIPE Atlas probes is about 10% lower for these compared to the control measurement. So, as with other address space in the RIPE NCC service region, it is advisable to create ROAs and/or Route objects, if you want optimal reachability of your address space. 

Conclusion

From the data we collected, we don't find strong indications that we should delay issuing IPv6 address space from 2a10::/12 . We conclude that by and large this new address space is operationally usable, and we will start allocating and assigning addresses from this range very soon.