IP Addresses in 2016 Geoff Huston APNIC
IPv6
IPv6 Allocations by RIRs Number of individual IPv6 address allocations per year
IPv6 Allocations by RIRs Year-by-year up and to the right Number of individual IPv6 address allocations per year
IPv6 Allocated Addresses Volume of Allocated IPv6 Addresses (using units of /32s) per year Year-by-year steady (+/- 20%)
IPv6 Allocated Addresses Volume of Allocated IPv6 Addresses (using units of /32s) per year Different regions, different IPv6 activity levels
Where did the IPv6 addresses go? Volume of Allocated IPv6 Addresses (using units of /32s) per country, per year
Where did the IPv6 addresses go? IPv6 Adoption rate per country (%) 5 of the 10 largest IPv6 allocations have been made into countries with little in the way of visible current deployment in the public Internet
Advertised vs Unadvertised
Advertised : Unadvertised (%)
Total IPv6 Holdings by country There is currently considerably disparity between countries as to the ratio between allocated and advertised IPv6 blocks. Taiwan, Sweden, Australia, Norway, UK and Netherlands appear to advertise a visible part of their allocated IPv6 address holdings Other countries have a far lower ratio of advertised to allocated address blocks Why?
IPv6 Allocations Many IPv6 address holders appear to want to avoid being “caught short” with IPv6, and have requested IPv6 address blocks that are far larger than their current immediate needs for public IPv6 addresses to be used across the public Internet This is consistent with an overall address management framework that is not overly concerned with conservation in use at present, so address allocations are not constraint driven This, in turn, is consistent with the IPv6 design choice to use a very large address field, so that such liberal address allocation practices could be sustained for many decades
IPv4
Addressing V4 Exhaustion We have been predicting that the exhaustion of the free pool of IPv4 addresses would eventually happen for the past 25 years! And, finally, we’ve now hit the bottom of the address pool! APNIC, RIPE NCC, LACNIC and ARIN are now empty of general use IPv4 addresses RIPE and APNIC are operating a Last /8 We now have just AFRINIC left with more than a /8 remaining
Allocations in the Last Years of IPv4
Allocations in the Last Years of IPv4 Pre Exhaustion Global Financial Crisis Exhaustion Profile
Where did the Addresses Go? Volume of Allocated IPv4 Addresses (using units of millions of /32s) per year RIPE NCC ran out in 2012 ARIN ran out In 2015 APNIC ran out in 2011 LACNIC ran out in 2014
What’s Left? (1 March 2017) Available /32s Reserved /32s Current Run Out APNIC 6,935,808 4,074,240 Last /8: early 2020 RIPE NCC 12,673,608 1,045,312 Last /8: early 2021 ARIN 0 6,115,072 LACNIC 68,096 4,924,672 AFRINIC 18,097,408 2,998,272 General: June 2018 37,774,920 19,157,568
IPv4: Advertised vs Unadvertised
IPv4: Unadvertised Addresses
IPv4:Assigned vs Recovered Growth in Advertised Addresses RIR Allocations 1.4 /8s 0.5 /8s Change in the Unadvertised Address Pool
The IPv4 After-Market: Address Transfers There is a considerable residual demand for IPv4 addresses following exhaustion IPv6 is not a direct substitute for the lack of IPv4 Some of this demand is pushed into using middleware that imposes address sharing (Carrier Grade NATS, Virtual Hosting, etc) Where there is no substitute then we turn to the aftermarket Some address transfers are “sale” transactions, and they are entered into the address registries Some transfers take the form of “leases” where the lease holder’s details are not necessarily entered into the address registry
Registered Address Transfers Number of registered Address transfers per year Volume of addresses transferred per year (/32s)
How old are transferred addresses? 70% of transferred addresses are >20 years old in 2016
But The RIR Transfer Logs are not the entire story: For example, the RIPE NCC’s address transfer logs appear not to contain records of transfers of legacy space Address leases and similar “off market” address transactions are not necessarily recorded in the RIRs’ transfer logs Can BGP tell us anything about this missing data?
A BGP View of Addresses Lets compare a snapshot of the routing table at the start of 2016 with a snapshot taken at the end of the year.
BGP Changes Across 2016 What is the level of correlation between these addresses and the address ranges recorded in the transfer logs?
BGP Changes Across 2016 8,663 announcements are listed in the transfer logs 117,982 announcements are NOT listed in the transfer logs
BGP Changes Across 2016 Listed as Transferred UnListed Rehomed All 1,539 15,389 9% Root Prefixes 1,184 9,551 11% Removed All 3,287 64,287 5% Root Prefixes 1,877 20,203 9% Added All 8,663 117,982 7% Root Prefixes 4,617 41,621 10%
“Age” of Shifted Addresses
“Age” of Shifted Addresses Some 20% of addresses that changed their routing state in 2016 are “legacy” allocated addresses that are more than 20 years “old” Addresses older than 20 years look to be more stable than the registry “norm” Addresses allocated in the past 18 months are more likely to have been announced (naturally!) Addresses that are 5 – 10 years old are more likely to have been removed from the routing system in 2016
BGP Data and Transfer Logs Some 5-10 % of address changes seen across 2016 (announced, withdrawn and re-homed) are listed in the RIR transfer logs That does NOT imply that the remaining 90-95% of address transfers are all unrecorded transfers But it does point to a larger body of addresses that have changed their advertisement status in one way or another, some of which may have involved leasing or other forms of address movement, that are not recorded in the transfer logs
Address Movement and the Registries It is not clear from this analysis what has happened in the case of the other addresses. This could include: ”normal” movement of edge networks between upstream providers (customer ‘churn’) Occluded multi-homing Address movement within a distributed edge network Address leasing Address transfers not recorded in the transfer registries More analysis is required to understand what is happening here
Thank You!