5.3 Merge window, part 1
5.3 Merge window, part 1
Posted Jul 23, 2019 15:49 UTC (Tue) by farnz (subscriber, #17727)In reply to: 5.3 Merge window, part 1 by nilsmeyer
Parent article: 5.3 Merge window, part 1
There's a degree of geographic luck involved, too - most of the developed world has enough IPv4 that there's no short-term shortage (no need to put everyone behind CGNAT, for example). IPv6 is thus something you do because you want it, not because you need it - it's worth it for the big players (Google/YouTube, Netflix, Facebook) because it lets you bypass CGNAT on mobile and in countries with IPv4 shortage, which improves your performance metrics.
In contrast, in a reasonable number of less developed countries, you're stuck behind CGNAT for IPv4 whether you like it or not, and need IPv6 if you want to run a server other than an onion service, or you pay for AWS/GCE/other services in a country with enough IPv4. If you're lucky, your ISP is sane enough to run 464XLAT or dual-stack; if you're unlucky, you're IPv4-only and have no choice but pay for Western services.
Posted Jul 24, 2019 7:33 UTC (Wed)
by jem (subscriber, #24231)
[Link] (1 responses)
According to Wikipedia, "RIPE NCC, the regional Internet registry for Europe, was the second RIR to deplete its address pool on 14 September 2012", after APNIC. AFRINIC was the last. The situation in North America may be a bit better.
Posted Jul 24, 2019 8:20 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
It's not the RIR holdings of IPv4 that matter - the run out of a RIR simply means that new ISPs in a region cannot get started. Instead, it's the IPv4 holdings of each ISP in the region that matter, as compared to the size of their customer base; if (to choose an example that has deployed IPv6) Comcast in the USA has 50 million potential customers in its service area, and a total of 60 million IPv4 addresses across all its ASes, it can shuffle IPv4 around to get one IPv4 per customer, minimum, and thus no CGNAT.
In contrast, if an ISP in Botswana has 50,000 IPv4 addresses (half the total assigned to Botswana), it can't offer one IP address per user in its service area (it has to CGNAT 7:1 if it claims the whole of the current Internet market in Botswana, and worse if the Internet grows). Because the RIRs are out, said ISP can only grow by buying addresses from someone else when it needs them - so the incentive is there to CGNAT.
Plus, you then have user expectations to take into account; in the USA, people expect the experience they get from stateless routing by ISPs, and NAT under their control; this means that CGNAT is expensive, because it has to maintain state in such a way that a single device failure does not lose a user's NAT mappings. In other countries, CGNAT can be cheaper because it's all the local users have ever known, so it can be unreliable, and that's just the way the Internet is.
And IPv6 is a mutual thing for the big players and mobile operators - T-Mobile loses demand on its CGNAT (which they like), and the big operators get improvements on their latency metrics (which they like). Note that, for example, just-in-time sending of the next chunk of video involves smaller chunks if the latency from server to client is lower, and you can spend more time preparing a page for the same TTI if the latency is lower.
5.3 Merge window, part 1
There's a degree of geographic luck involved, too - most of the developed world has enough IPv4 that there's no short-term shortage (no need to put everyone behind CGNAT, for example).
[IPv6 is] worth it for the big players (Google/YouTube, Netflix, Facebook) because it lets you bypass CGNAT on mobile and in countries with IPv4 shortage, which improves your performance metrics.
Google (including YouTube) and Facebook are doing operators like T-Mobile a big favor, because they generate a large portion Internet traffic, which means packets between the handset and YouTube doesn't have to go through NAT64. It's all end-to-end with no address or protocol conversion, like the Internet was originally designed to work, only using IPv6 this time.
5.3 Merge window, part 1