The RIPE region is moving closer to removing needs assessment from its policies governing initial IPv4 address allocations and secondary transfers. While support for that change has steadily grown, there remains a vocal minority insisting that operators submit documentation to a central bureaucratic authority which reviews some technical indicators in order to justify their need for addresses. However, what is absent from this discussion is any empirical evaluation of if and how the requirement of needs assessment is related to use of addresses. Our 2012 study of the emergent secondary market provided some early indication of the relationship between needs assessment and use of addresses. In it, we noted how one company (Microsoft) was, at the time, only routing a small portion of the blocks it had acquired in the secondary market. This piqued our curiosity – are numbers sold in the secondary market that do go through needs assessments immediately put to use, as the needs assessment is intended to enforce?
To shed some light on this, we collected additional data on each of the 309 address blocks (comprising 9.2M addresses) transferred in the market under RIR governance regime. We looked up on a semi-annual basis the associated routing information, i.e., the public advertisement of the AS number routing the block as represented in Route Views. Blocks were then coded on three dimensions. First, whether or not routing information had been updated over the time period evaluated. Second, whether or not a block was routed or unrouted currently (i.e., as of 2H 2013). Finally, for routed blocks, we determined whether the block was being routed by the organization which transferred it, the acquiring organization, or a third party (typically an ISP).
Assuming a transfer between unrelated organizations, one would expect to see the routing information updated to a new AS or, at a minimum, unrouted status. Furthermore, one would generally expect that after a certain period following a transfer a block will be routed publicly, if the point of address governance is to move scarce resources to where they will be utilized in the Internet. Of course, one can imagine exceptions; a company could acquire blocks in recognition of the long term value of globally unique addresses, and route them privately on an interim basis.
Data
Table 1 below breaks down the routing status for blocks that have had their routing information updated. Of these 259 blocks, 230 are being publicly routed. 203 of the 230 are being routed by the organization acquiring the transferred block, 25 by a third party, and curiously, the remaining 2 by the organization that transferred the block.
Table 1: Transferred blocks with updated routing information
/ Notation | Number of blocks this size transferred | Addresses per block transferred | Number of blocks routed | Number of blocks unrouted |
/12 | 3 | 1,048,576 | 3 | 0 |
/13 | 3 | 524,288 | 3 | 0 |
/14 | 4 | 262,144 | 3 | 1 |
/15 | 4 | 131,072 | 3 | 1 |
/16 | 27 | 65,536 | 19 | 8 |
/17 | 6 | 32,768 | 6 | 0 |
/18 | 11 | 16,384 | 10 | 1 |
/19 | 19 | 8,192 | 17 | 2 |
/20 | 26 | 4,096 | 22 | 4 |
/21 | 12 | 2,048 | 11 | 1 |
/22 | 31 | 1,024 | 28 | 3 |
/23 | 19 | 512 | 17 | 2 |
/24 | 94 | 256 | 88 | 6 |
Sum | 259 | — | 230 | 29 |
29 blocks were transferred and are unrouted. Three of the largest transfers include blocks going to Vodafone Americas (331,776 addresses), Microsoft (196,608 addresses), and Amazon (131,072 addresses). Interestingly, eight of those 29 blocks transferred were never routed over the entire time period observed.
Table 2 below breaks down routing status for blocks that did not have updated routing information. Fifty (50) blocks did not have updated routing information. Half of them (25) are unrouted, while 25 are still publicly routed. 9 blocks were being routed by the organization acquiring the transferred block, 7 by a third party, and 9 by the organization transferring the block. 64% of the non-updated, but routed blocks were transferred in the APNIC region.
Table 2: Transferred blocks with routing information not updated
/ Notation | Number of blocks this size transferred | Addresses per block transferred | Number of blocks routed | Number of blocks unrouted |
/16 | 4 | 65,536 | 2 | 2 |
/17 | 2 | 32,768 | 1 | 1 |
/18 | 1 | 16,384 | 1 | 0 |
/19 | 4 | 8,192 | 1 | 3 |
/20 | 6 | 4,096 | 2 | 4 |
/21 | 3 | 2,048 | 1 | 2 |
/22 | 4 | 1,024 | 2 | 2 |
/23 | 5 | 512 | 4 | 1 |
/24 | 21 | 256 | 11 | 10 |
Sum | 50 | — | 25 | 25 |
Looking again at blocks which had routing information updated, Table 3 below gives a sense of how long it took for blocks to become routed by the acquiring organization or third party. Of the 230 blocks, 113 were routed within six months of the transfer date. 48 more blocks were routed within one year, and 54 blocks were routed a year or longer after the recorded transfer date. Strangely, routing information for 11 blocks was updated 6 months or more prior to the transfer date, while 2 blocks continued to be routed by the transferring organization.
Table 3: Months before blocks routed
/ Notation | Number of blocks this size transferred | Addresses per block transferred | 6 months or fewer | Between 6 and 12 months | Between 12 and 18 months | Between 18 and 24 months | Greater than 24 months |
/12 | 3 | 1,048,576 | 1 | 1 | 1 | – | – |
/13 | 3 | 524,288 | 1 | 2 | – | – | – |
/14 | 3 | 262,144 | 1 | 2 | – | – | – |
/15 | 3 | 131,072 | 1 | 2 | – | – | – |
/16 | 19 | 65,536 | 5 | 6 | 1 | 6 | – |
/17 | 6 | 32,768 | 1 | 3 | – | 2 | – |
/18 | 10 | 16,384 | 7 | 3 | – | – | – |
/19 | 17 | 8,192 | 5 | 6 | 1 | 1 | – |
/20 | 22 | 4,096 | 7 | 7 | 2 | 2 | 2 |
/21 | 11 | 2,048 | 3 | 3 | – | 2 | 2 |
/22 | 28 | 1,024 | 16 | 5 | 3 | 3 | 1 |
/23 | 17 | 512 | 8 | 3 | 1 | 3 | – |
/24 | 88 | 256 | 57 | 5 | 6 | 13 | 2 |
Sum | 230 | – | 113 | 48 | 15 | 32 | 7 |
Discussion
In general, our preliminary look at the relationship between transfers and use of addresses is much more complicated than expected. One cannot always expect to observe the transfer of a block to a new organization, followed by their routing of the block. Nonetheless, we think the data allow us to make a couple observations regarding the transfer market and related policies.
Take for example blocks where routing information never changed before or after the transfer date. The organization named as being in control of the block may have changed as a result of completing the transfer according to RIR policies, but de facto use of the block did not. This calls into question whether these are actually market transfers at all. We noted in our earlier study that APNIC transfer data does not distinguish between market transfers and internal transfers. If some of these transfers aren’t true market transfer, then the number of transactions is somewhat less than previously reported, particularly in the APNIC region. Does this matter? Well, one would think buyers and sellers would want an accurate picture of the market. One policy change to consider would be for APNIC to clearly separate market transfers from internal transfers in its reporting. A more meaningful reform would require transacting parties to provide the price of a sale, so that we would know it is an arms-length transaction. Regulators and economists would suggest that availability of more detailed price information is a requirement for a smoothly functioning market. Unfortunately, those involved in transfers would likely be against sharing such information. But even a general indication of whether or not the transfer was for remuneration would be helpful.
Most blocks with updated routing information appear to be routed within 12 months of the transfer date. Some might simply claim that this proves that needs assessment is working. However, we do not know how quickly they would or would not be used without needs assessments. Even with the needs assessment requirement, there is great variation in the time periods between transfer dates and when block(s) were routed. 7 blocks were not routed after 24 months, exceeding the time span for assessing need. There doesn’t appear to be any predictable relationship between time to route and block sizes, although most of the blocks not routed after 2 years were smaller ones. There are also exceptional cases in which larger buyers did not quickly utilize the blocks they acquired. E.g., Microsoft started to route most of its acquired blocks in the first half of 2013 – more than a year and a half after the transfer date and our initial publication of the discrepancy. So the relationship between needs assessment and actual usage is not entirely clear.
For smaller blocks (/20 – /24), the percentage of blocks not routed until 18 months or longer after the sale is distinctly higher. For /21 blocks, 36% of the 11 blocks transferred were not routed until 18 months or longer, and for /24 and /23 blocks, 17% took longer than 18 months to route. This suggests that RIPE’s elimination of needs assessment in the distribution of its last /8 in small, one-to-an-organization units of /22 blocks would make less of a difference than one might think.
Another policy approach, less radical than eliminating needs assessments altogether, could require buyers of number blocks to route acquired addresses within a specific time frame. It would be a lot less murky and time consuming than needs assessment, but would probably mitigate anti-competitive hoarding just as effectively. Similar usage policies have been implemented in other resource regimes (e.g., radio spectrum).
We welcome your comments.
Brenden,
Nice article. I like the policy suggestion of ensuring the space is put to use over some reasonable time frame. ARIN probably would rather administer upfront, instead of having to police, and threaten to take back once the horse was out of the stable. I think a variation on the theme would be if a company requests space within a reasonable boundary and not inconsistent with what they have requested in the past, the request is granted (with a ceiling limit for large requests of ~/12 or larger). First, this is better for the routing table (company gets a /18 instead of a /21). Second, this would favor the smaller companies who are unduly punished under the current construct (incumbents can “justify” so much more of the diminishing resource, positioning them more firmly post exhaustion).
Obviously, the fact that a block of addresses does not appear to be routed from your particular vantage point on the Internet does not necessarily imply the addresses aren’t in use. With that said, it might be interesting to compare the time-to-routing of “traditional” allocations versus transferred allocations.
Thanks for sharing superb informations. Your website is very cool. I am impressed by the facts that you
Very interesting study. Thanks for sharing this data with us! I will recommend this article further, to my friends!
I would use an IP adress as soon as I bought it. Or, better said, I would buy an IP adress when I need it and use it immediately. That is my concept, but I believe, on real terms, this can have nuances. So, a study like the above is really welcomed from specialists.