Address Assignment Practices in IPv4 and IPv6

ISPs assign parts of their address space to users and subscribers. These assignments are typically not static. Often in a domestic network, a subscriber's CPE will negotiate a lease on an individual IPv4 address or an IPv6 subnet via a DHCP or RADIUS exchange.

How long do these assignments last for? In IPv4 it's common for users to receive an individual address, but in IPv6 entire subnets are delegated. How large are those subnets? There are BCP recommendations that steer networks towards particular subnet sizes, but networks are free to select subnet sizes according to their own addressing plans. Can we observe the size of the subnets that are assigned from measurement data?

The duration and size of assignments has various implications:

• Reputation: If you're a content or service provider who occasionally has to block abusive behaviour from the network, what is the potential collateral damage?
• Geolocation: If you generate geo datapacks, how reliable do your customers consider them? If you rely on geo datapacks, how stale might they be?
• Measurement: If you're a network researcher attempting to scan active portions of the IPv6 address space, how much of an ISP's space is in use and how is it subdivided?

Ongoing Measurements

RIPE Atlas runs, among other built-in measurements, echo measurements. These are HTTP requests from probes to servers operated by the RIPE NCC, the response to which contains the IP address observed by the server. These measurements therefore report the publicly visible address from any probe, whether it's a globally visible IPv6 address or the shared address on an IPv4 CGNAT. The measurements run every 15 minutes, giving us a dataset of IPv4 and IPv6 address changes over many years. Given we know which probe performs each echo request, we have data on when each probe's IPv4 and IPv6 addresses change, and whether or not those changes are synchronous.

The RIPE Atlas platform has extensive coverage in some networks, but not all networks. In addition to the RIPE Atlas dataset, we make use of data from a large CDN. This dataset contains address associations purposefully constructed from browser sessions where a resource has been requested over both IPv4 and an IPv6. The IPv4 addresses are masked to /24s and the IPv6 addresses are masked to /64s. This dataset gives us a bound on when two addresses appear to have been assigned to the same user. Utilising five months of data, we have over 30 billion address associations in this dataset, allowing us to cover more networks than with the RIPE Atlas dataset alone.

We make use of this larger dataset in the full paper (linked at the bottom of this article). In this article, we'll look more closely at the RIPE Atlas dataset and related data in the RIPE database.

Address Lifetimes

The long-term scarcity of IPv4 addresses and intermittent connectivity (e.g., dial-up connections) led networks towards leasing IPv4 addresses from shared pools. Leases expire, and networks differ on how sticky addresses are or how long a lease should last. IPv6 deployments have taken place in a different era, where many more connections are likely to be always-on, and the scarcity argument is removed.

In Figure 1, we show the difference between address assignment lifetimes in IPv4 and IPv6.

Figure 1: Frequency of assignment durations in IPv4 and IPv6 environments. Strong vertical lines indicate Y% of time is spent with the durations on the X axis.

To understand the above plots, consider Deutsche Telekom (DTAG). On the left, we show IPv4-only probes, and on the right IPv6 (largely dual-stacked) probes. The vertical lines indicate common address durations; IPv4-only hosts appear to spend just under 60% of their time with 1 day assignments (or shorter), while the IPv6 durations are typically longer than 1 day (over 60% of their assignments persist longer than 1 day). In the paper, we additionally show that IPv4 lifetimes for dual-stacked hosts tend to have longer lifetimes than for single-stacked IPv4 networks, if not quite as long as IPv6 prefix delegations.

We see a clear divergence between how long IPv4 and IPv6 assignments persist in these networks. Indeed, we observe that IPv6 assignments tend to persist longer in most networks. This distinction between IPv4 and IPv6 may be important to consider when determining how long to block abusive behaviour or how stale to consider geo data, for example.

Delegated Prefixes

ISPs delegate an IPv6 prefix to each subscriber, but the size of that delegated prefix is decided by the ISP. A natural lower limit on the size of the delegated prefix is /64, though best practice suggests that larger subnets should be defined. ISPs are not consistent in how they delegate prefixes, nor do they have any need to be! Some ISPs describe their address architecture for subscribers publicly, and some do not. What can we glean instead from measurement data?

We take a simple approach to identifying the size of the prefixes assigned to a network: count the zero bits prior to the /64 boundary. The notion of prefix delegation entitles CPE or network operators to subdivide their network as they see fit, but the intuition is that many networks choose to keep things simple and their CPE uses the zeroth /64 in the delegated prefix. Taking this simple approach, we are able to identify patterns per-network in Figure 2, based on those runs of zeroes in the addresses.

Figure 2: Inferred delegated prefix lengths from RIPE Atlas data. Y% of probes in a given network appear to have a delegated prefix of length X. The value in parenthesis on the right is the number of probes in the dataset for that ISP.

Across these networks, where we have many probes and many address changes to inspect, we observe some distinct signals:

• Many, but not all, networks appear to be assigning /56s to customers
• Networks that stand out from that include:
  • Comcast, which typically appears to assign a /64
  • Kabel, which typically assigns a /62
  • Free, which typically assigns a /60
  • Deutsche Telekom has two spikes, at /56 and /64, and this appears to be driven by a distinction whereby a /56 is issued and some CPE models cycle through multiple /64s in that space.
  • Netcologne, which typically assigns a /48.

So using this data alone, we can already observe that there's a wide variation in how much address space each ISP is willing to give their customers.

Assignment Size Data in the RIPE Database

It is useful for anybody outside of a network to know the size of the prefixes assigned to customers. Some operators publish their addressing practices on the web, but one additional means to share information -- which we don't touch on in the paper -- is via the RIPE database (a.k.a., whois).

An LIR -- in our case, domestic ISPs -- with IPv6 space can subdivide that space and ultimately assign parts of it to end users. LIRs are obligated to describe their IPv6 assignments in the database. An overview of how to document IPv6 assignments in the RIPE database is available here. In short, inet6num objects may describe a specific assignment to a customer, or may describe a pool of space from which assignments are made to customers.

The latter category of objects have the status AGGREGATED-BY-LIR, and inet6num objects with this status must include an assignment-size parameter. This parameter states the block size that end users should be uniformly assigned from within the address space described by the object.

There are 44 thousand inet6num objects with an assignment-size attribute. The values registered typically align with what you may expect: the most common listed assignment-size is /56 (in over 81% of the inet6num objects), then /64 (11%), then /48 (6%). The remaining values are fewer than 2% of the registered assignment-sizes, including 244 /128s; it'd be interesting to know how people are using network prefixes longer than /64!

The data in the database may be reliable as a means to verify our measurements above. In order to align these two datasets, in Figure 3 we've taken the same set of probes and the /64s that were observed from those probes as we used for Figure 2. But instead of inferring the delegated prefix from the bits we saw active, we search the RIPE database for the covering inet6num object, and look for an assignment-size value in that object.

The results look as follows:

Figure 3: Registered assignment-size values in the RIPE Database for the prefixes assigned to probes. Percentage of probes refers to percentage when assignment-size information exists.

Note that some networks aren't registering this field (or they exist out of the RIPE region), so for those networks we have nothing to compare. We have data for Deutsche Telekom, Liberty Global, Kabel DE, Free, Netcologne, BT, and Sky.

We have a few observations to make in the above:

• There's a clear intent across these networks to select /56s for delegation to subscribers, which is good. That both fits with BCOP-690 and with the patterns measured in Figure 2.
• Deutsche Telekom clearly issues a /56, according to the database. This is a clear distinction to the split in Figure 2 between the identified /56s and /64s, typically a distinction in CPE behaviour. Our heuristic was deliberately simple, and with a little more work we should be able to detect cycling within a common subnet.
• Netcologne (AS8422) provides a /48 to all probes that we have address change data for in Figure 2, and indeed the database agrees in Figure 3. A full 16-bits of address space for their customers!
• Liberty Global (LGI) has operations across many countries and for LGI prefixes with matching assignment-size data, we see a split between /36s and /64s. The /36 value comes from Cablecom in Switzerland, though in Figure 2 we observed nothing close to a /36 and so that feels like bad or stale data in the database. The /64 value comes from T-Mobile Austria, and so likely represents assignments to mobile subscribers. Figure 2 reveals probes that appear to have been assigned a /56, so we presumably are simply identifying parts of LGI that aren't lodging this data in the database.

We'd love to be able to get more of the networks we've studied specifying this information publicly, and the RIPE database seems a trustworthy means to enable this. The partial data we have above seems like it'd be useful for the applications outlined at the start of this article.

Implications

Understanding domestic stability of the IP address space -- be it temporal or spatial -- is useful for various applications. The key here is that assumptions from the IPv4 world may not carry to the IPv6 world.

But this might not be such a bad thing. For example, if a service is typically willing to drop traffic from a single IPv4 address for 24 hours to dampen some malicious behaviour, that same heuristic applied to IPv6 is likely to be too short rather than too long. That's a reasonable position as an operator: the collateral damage is lessened.

Similarly, a block on a single /64 is likely to be too narrow: a knowledgable attacker could select a subnet elsewhere within their /56, and then you may have a game of whack-a-mole on your hands. But since a /64 is an atomic unit of IPv6 networks, it's also likely not to block more than one household in the first attempt.

More per-network knowledge is useful for everybody, and it's likely to be in the community's best interests if networks publicise more about their addressing plans.

The Study

There's much more detail in the full paper which we presented at CoNEXT 2020, so go check it out! We have additional graphs available on this web page. And if you prefer video form, the short (12.5 minute) video for our paper is here: