I wonder if they will implement some kind of clawback for orgs that are sitting on large chunks of sparsely used blocks. Old tech companies and colleges come to mind.
I doubt that, but I think we're going to see more and more companies to sell off the unused blocks. Last year MIT sold off 1/2 of 18.0.0.0/8 to Amazon.
It looks like the going rate per IP is between $20-$24 currently:
Very few companies would need to decide to not interconnect with IPv4 networks before IPv4 was effectively dead. Typically, though, there's a process that they would go through before making that move. That's what I was asking about. Has anybody floated a date for IPv4 death?
Those very few influential people who make the decisions are incredibly conservative; they won't even kick criminals off the Internet without overwhelming evidence. I don't think they're even interested in discussing IPv4 sunset at this point.
Rather than a date I think it would make sense to look at the traffic. When IPv4 hits, say, 1% it might make sense to turn it off. I would estimate that's decades away.
That's true. However, even if they just said IPv6 destinations will be used in the ranking algorithm as a positive indicator of a site that's being actively maintained, that alone would be enough to get some people moving.
Who is 'they', and under what authority? If you're thinking about RIPE or ARIN, legacy block allocations predate those organisations even existing. They have no rights over that space.
At the same time, IANA has delegated 'future' (read: sometime in the past, but not until after those legacy allocations) responsibility to the RIRs (ARIN, RIPE, APNIC, LACNIC, AFRINIC).
Finally, how do you determine whether or not space is used? Ping? BGP announcements to the Internet of the space? Neither of those concludes that the space isn't used, and RIR policies permit for registration of globally unique addresses without any obligation to announce to the Internet.
Not sure on who "they" is, to be honest. But if/when ipv4s become very difficult to obtain, lots of potential "theys" will likely emerge. Powerful companies and governments won't just shrug it off.
At some point the cost of doing all of what you mention is more than the cost of NAT64/46 infrastructure to enable the problem to actually be fixed for more than a couple of years at a time.
When the options are: let them profit awkwardly from a windfall, claw it back against their will, or make their IPv4 assets obsolete, focusing on the latter seems most productive.
The UK’s largest mobile provider now gives me an IPv6 only connection and I didn’t even notice.
Apple have made it a hard requirement for apps to operate correctly on IPv6-only connections for a few years now. If your app doesn't work unless it's on IPv4, Apple will reject it.
Apple's mandate happened because a couple US Telecoms asked them to. The US has plenty of cell towers that are IPv6-only, and at least a couple US carriers are now IPv6-only or IPv6-primarily, with more planning to switch. All the carriers have big NAT64 gateways of course to keep the internet from entirely breaking, but that's still an avoidable bottleneck from a backend perspective. Apple themselves may not be dictating what the backend is doing, but they are doing a lot of Happy Eyeballs [1] tests on your backend and IPv6 without NAT64 proxies in the way is likely the fastest experience for a lot of real mobile users today.
Apps can't request IPv4 addresses directly (ie, no hardcoded IPv4 addresses allowed), but DNS may still return them for indirect use (via the Happy Eyeballs [1] approach that heavily favors IPv6 because an increasing number of mobile carriers are IPv6-only or IPv6-primarily and IPv4 addresses must get sent to NAT64 gateways).
Not only can it be true I've done it at a conference, which is to say I've implemented an IPv6 only network for conference delegates and had zero connectivity complaints.
The ingredient you are missing is while the clients only talk IPv6, the gateway they go through (must) have both IPv6 and IPv4 addresses. There is a well defined mapping from IPv4 to IPv6 addresses, so if the IPv6 clients need to communicate with a IPv4 only host they use it's mapped IPv6 address. The gateway then NAT's all those mapped IPv6 addresses to it's IPv4 address.
Which only leave the problem of does an IPv6 client know to use an mapped IPv4 address, given it is supposed to know nothing about the IPv4 world. The answer is you make it use a DNS server that lies. I'll leave it to you to figure out exactly how it lies, but it isn't hard to figure out given it has clients that only understand AAAA records, and some hosts (such as twitter) that only resolve to A records.
As far as I understand from previous discussions, those blocks (1) can't be split among a bunch of providers, since it would bloat routing tables and (2) wouldn't extend the timeline very much, so it's not worthwhile engaging in that fight.
I just disabled IPv6 at home. Again. Been running it for a year now, but ended in tears. Again.
Gave up on trying to figure out how to make it all just work. I'd rather take one public IP that works than 9223372036854775808 that doesn't.
Mainly there seems to be a big disconnect between how IPv6 is designed and intended to be used (according to modern RFCs), and how at least my ISP actually deploys it. For one they only give me a /64, which isn't compatible with modern IPv6 ways. In addition they do so using DHCPv6, which means my prefix changes every now and then. All those internal services that got their own IP needs separate DynDNS entries. All those firewall rules opening ports for those services? Yeah they need to be manually updated.
Local DNS resolution fails because the DHCP server in pfSense sends out the public IPv6 address as the primary DNS rather than the local IPv4 I added manually to try to override it, so now my devices try to contact a DNS server that doesn't exist.
I'm sure some day it'll actually just work for me...
Instead of excluding CF, I'd like to see server stats weighted by popularity. I'd bet that the concentration of traffic to just a few mega-sites means most people can now get by just fine with IPv6.
You might be surprised. For reasons I can't begin to fathom, a coffee shop near me used to have its wifi router set up to only permit connections to external sites over IPv6. I was legitimately surprised at how many sites I couldn't access from there, including sites from Fortune 50 companies and big tech firms, who you'd expect to be among those who'd be on top of this sort of thing.
Enterprise has a lot less pressure to switch, because they have existing capital investments into, for instance, large, expensive IPv4-only firewalls that aren't currently "broken", and large private IPv4 subnets already walled off with enough IP addresses for their device/asset catalogs.
It maybe shouldn't be a surprise that IPv6 has seen much faster consumer adoption comparatively, as consumer ISPs face much less steady/predictable device growth and sometimes much more complex routing scenarios (cell towers have much more complicated internet traffic routing needs than wired ethernet in an office park somewhere).
This is much less important. A legacy v4-only server can be reached from v6 via NAT64 (which basically works like NAT but with v6 on the inside), so there's no particular need to get rid of all of them.
It's much more important to get rid of legacy v4-only clients, to make it possible to run v6-only servers.
The server side story is terrible. Until I switched my stuff to Ubiquiti, I was having a recurring issue where my old TP-Link router would lose its mind and refuse to pass any IPv4 traffic, but IPv6 was fine.
The result? Facebook, Google, and Netflix still worked, but the entire rest of the internet would just disappear— poof.
I'd guess adoption will look less like an exponential or straight increasoming function and more like a sigmoid. As more people adopt, those left will be the increasingly resistant. Eventually, IPv4 re-sale markets will get pricey enough that bean-counters will insist.
I doubt it on the bean counters, resale will trail off and stop being interesting. The IPv4 address space isn't big enough for the whole world, but it's easily big enough to indefinitely handle millions of holdouts left on legacy systems.
Eventually they stop being enough traffic to make them uninteresting to the backbone, and the backbone becomes IPv6-only - but the v4 Internet still exists, in a sense, as a bunch of networks connected via IPv6 translation gateways. Perhaps for a century or more.
Right now if you're a large organisation it makes sense to go IPv6 only internally and translate at your border. All your address headaches vanish immediately (remember trying to figure out how to cut up groups of systems so they'd fit in neat binary subnets in IPv4? Not a problem in IPv6, any conceivable number of machines will go in a one-size-fits-all IPv6 /64 Ethernet subnet) and you now have no future IT transition problems, because internally transition is finished. You own some translation gateways to connect your IPv6 clients to anything from the legacy IPv4 Internet and over time the traffic through those decreases so that cost will diminish. Whether the rest of the world takes 50 years or 15 to upgrade it's just a tweak to the budget for the translation gateways, everything else stays the same for you.
IPv6 isn’t such a monster, I found, after biting the bullet seriously last year. There are still way too many IPv4 only sites though.
As with anything IP related there’s a culture that’s just as important as the technical side. If your ISP gives you anything less than a /56 for your site (a VPS running multiple containers is a valid definition of site!) take your business elsewhere.
There’s a lot of hyperbole about v6 address space, but even taking account of its sparseness, IP rationing really is for v4 only.
For every /24 allocated to an LIR (NB 2 bits fewer than the subject of this RIPE bulletin) they can assign as many sites a /56 as there are current IPv4 addresses in total.
Why would you do that? The promise of IPv6 to me is that all devices gets their own IP address, enabling us to move away from the server-client architecture of the internet. Allocating all IPv6 addresses to commercial server operators would require us to continue using NAT, so then we might as well continue using IPv4.
There is no address allocation scheme that would force you to use NAT on IPv6.
A lot of people don't really understand exactly what moving from 32bit to 128-bit addresses means.
Let's say that we waste 65535/65536, or about 99.9985% of IPv6 address space on pointless allocations, leaving only one /16 left. This still means there are 5 192 296 858 534 827 628 530 496 329 220 096 addresses left to allocate, or 5*10^30, or enough addresses that if we had to distribute them to a trillion people per planet living on a trillion planets, they'd still get 5 billion addresses per person.
Part of demystifying IPv6 was that in practice the most significant 64 bits are the limiting factor. It helped me to put more manageable numbers on things.
Each ISP can have 65k customers who are big orgs with complex site needs and a /48, or 4 billion small customers getting a bundle of individual networks on their /56.
In the latter, each has address space for, say, 256 VLANs which allows network isolation of many internet enabled fridges.
And in theory the current scheme allows for 16 million ISPs to exist, though in practice not all the address space is available.
There really is more than enough address space. The 24bit prefix for each Local Internet Registry means each assignment is its own internet of internets, with enough breathing room for multiple levels of hierarchical assignment, and still with 64bits leftover on the LANs for clients to randomly assign themselves scores of addresses without fear of collision.
I'm curious if there are people here that have migrated their home network to IPv6 only, and if yes, what are the challenges encountered? I suspect the biggest problem is that there still are many websites that only have IPv4
IPv6 only is a bit daft as yet because you'll need a 6 to 4 gateway of some sort to see much of the web/internets. For starters, this:
$ dig news.ycombinator.com AAAA
... fails
I have been running dual stack at home for around five years now with only a couple of wobbles that I can point at my ISP losing their IPv6 and not noticing for a while.
I have a NAT64 translator handling the translation, plus a DNS64 server to point clients to it. You probably don't have those, because it's typically easier to run native v4 instead. I just wanted to make the point that v4-only websites are totally not a problem.
As others have said NAT64 is your friend. Other than that I never thought about it since the day I flipped, it's not really as big a change as people make it out to be.
Literally like the difference between HTTP/1.1 and HTTP/2. Yeah not all sites use HTTP/2 yet but how often would you notice if you didn't go looking for it?
If you have a beefy router, you can install Tayga[1] to do the translation from 6-to-4 for all client devices. Then you can use Google's DNS server or run your own, to translate IPv4 addresses in the replies into IPv6 equivalents.
How does this apply to email delivery? The biggest factor is having a "clean" IP address. Do these eventually become prohibitively expensive? Does email protocols switch to IPv6 and stop considering address reputation?
Currently as only a handful of providers even support receiving IPv6 mail and due to spammers still using IPv4, we don't know yet. Usually /64 is considered for reputation in abuseipdb.
Another fact is gmail which supports IPv6 requires a PTR pointing back to the domain the mail is sending.[1] Currently a lot of providers which gives IPv6 does not support adding PTR records for IPv6, because it is handled differently than IPv4. This has led to lot of people defaulting to IPv4 when sending mail.[2]
I never considered that it could be that way. That would be really nice: new domain, new reputation. Domains cost money, so that's good against spammers in general. And it's good for me, because my domains never sent any spam.
Anything changed recently? I got into quite some issues when migrating my mail server a few years ago to a new host, which led to the need to change the server's IP address.
I always thought that basically the only difference between IPv4 and IPv6 is the number of bytes in an address.
Lately I've been learning a lot more about IPv6 and there are a TON of subtle differences in the protocols that matter if you're operating a large network. Random example I recently read about: the way link-local addresses are generated. [0]
Not that this excuses inaction, but it does give me more empathy for orgs struggling with, or not doing, the transition to IPv6.
What happened is they changed a bunch of things about the protocol because they thought it would be a very forced adoption. Instead, it caused lagging adoption because of all the changes.
If IPv6 was just IPv4 with extra addresses, the adoption rate would have been very quick.
I hear this a lot but being in the networking but the only 3 complaints I actually hear in the field are "those addresses look a lot harder to type out", "our device doesn't support IPv6 (at all/fully)", and "can we hold off on that project another year or will things start breaking before then?". Not once has any of the protocol additions that always get talked about been a stopping point. I finally got the opportunity to roll it out on some of our guest wireless networks, it was literally a matter of assigning some space, flipping some settings on, and making sure Google still loads.
Ironically the techs did complain about the addresses looking funny in the Firewall logging.
On the other hand, you really do not get many chances to re-architect a universally used network protocol. It's important to make changes with a long-lasting impact.
A million times this. A lot of "ivory tower" style conversation go on about "there would too many changes", "it has design flaws", "it should have been backwards interoperable from day 1" but at all of the companies I've been a network architect for the only thing that was ever actually a holdback on a v6 rollout has been the business asking why they would do it now when they'll still need v4 after and v4 works at the moment.
We're still waiting for the processing of our application from beginning of September, I hope we can still get at least a /24 block. We mainly plan to use it to become independent of specific cloud / IT providers and control more of our infrastructure stack.
Not if you want to do things like E-Mail or provide stable IPs to customers. Also you'll get a more direct uplink and have more control over what traffic goes in or out (since you can blackhole traffic yourself).
IPv4's inability to label all the things may be a feature. NAT's are like borders in some ways, and prevent fine grained censorship without larger consequences.
The opportunity to make money off an arbitrarily scarce resource is in my opinion a reason we haven’t seen more network operators pushing users towards IPv6.
IPv4 runout can be be pushed far into the future with DNS SRV records. This is a preventable emergency. Why it hasn't be included in HTTP/2|3 is mind boggling.
HTTP/1.1 and forward includes name based virtual hosting (brought through TLS with the SNI field) and it's been extremely widely used. Seems mind boggling to suddenly want to change that for no additional gain.
It’ll be very intersting to see if this is enough to push ISPs to adopt IPv6 en masse, or they’ll keep dragging their feet and use nasty hacks like CG-NAT to avoid it.
The more ISPs migrate to IPv6 and CG-NAT, the more free IPv4 addresses for everyone else. Wich means the migration will take a really long time.
Also the only way to reach an IPv6 target from a IPv4 source is through a CG-NAT, so dual stack IPv6+CG-NAT deployments should be the norm for many years to come.
Value of product that can be sold per IP address: $5 - $1000/month.
Having worked in an organisation that had millions of addresses, we opted to carry on having a long term sustainable business over selling our IPs for short term gains.
Eventually the addressable market on IPv6 will reach a critical mass. At that point, the value of IPv4 will become relevant to niche markets only.
Once IPv6 is available widely enough, prices for IPv4 addresses will plummet because there is a nearly unlimited amount of IPv6 addresses available for much cheaper or free
In Germany i see most ISPs adopting IPv6 by using DS-Lite[0] which is basically handing out only IPv6 addresses and using CGNAT for IPv4 connectivity by mapping IPv4 addresses into IPv6 address space on the CPE. I don't like that at all as it makes you practically unreachable from the IPv4 address space. In order to get IPv4 addresses you often have to convince them on the phone and describe your use case. When you've done that you will get IPv4 address but no IPv6 addresses anymore. I have no idea why they seem to be so reluctant to a true Dual-Stack solution....
You have to be careful to distinguish what's going on here and who you are getting the IP addresses from.
When RIPE is out, the only way to get more addresses is by buying or renting them from somebody else who has a commercial interest to sell or rent you IP addresses or to control what you are doing with them.
With RIPE running out, there is no more way to get an IP address without asking a commercial third party for permission to be a part of the internet.
This will lead to a further centralization of the internet as the owners of big blocks will make sure that their blocks get even bigger so they can ask for rent for what was previously available for (mostly) free.
This isn't about saying that this is the end of the internet and the end of the ability for people to get on the internet, but it's definitely a huge change in landscape that we are going to feel as time goes on and we still refuse to go IPv6
Which makes sense considering that the exact same companies who would need to do something to get IPv6 going are also the same companies who have the most to gain from address scarcity.
When did they cry wolf over this? They've made various announcements at each stage of running out, but this is the first time they've announced that they have more pending LIR applications than blocks to assign to them.
nice of them to admit last times it wasn't serious then ;D they been calling this out since advent of ipv6 >.> are they just trying to sell ipv6 or what? since a lot of companies move to cloud solutions i can imagine this being less of an issue and a lot of blocks to be returned to the pool?
RIPE is one of five regional Internet registries that manage allocations for their respective regions, and all of them have announced the exhaustion of their pools of available address blocks of various sizes at various times over several years, as you would expect. Which of these announcements do you think weren’t serious?
They were panicking about IPv4 running out 20 years ago, the amazing inventions of NAT and CIDR meant it never happened. I predict that we’ll be here in 20 years again.
If you look at the mobile telco IPv4 blocks, or lack thereof, you'll see that NAT is here, heavily, almost ubiqitously, as carrier NAT. It's destroyed the network functionality of mobile telecommunications (lacking routable ipv4) and made them essentially dumb terminals lacking any ability to participate in the 'net. They can only consume other's services.
I don't know how I feel about this. IPv6 is the obvious answer, but maybe some kind of NAT is warranted for devices that tend not to have firewalls?
If each LTE terminal has a publicly routable IP, unless it's statefully firewalled, any random Internet user who can figure out my IP can run up my data bill, or packet me and inflict a Denial of Service. I remember long ago, some mobile operators in the U.S. were assigning public (non-firewalled) public IPv4 IPs to mobile devices... Attackers were literally scanning Sprint's mobile IP ranges for open port 22 and logging in over SSH as root/aspen to hack jailbroken iPhones!
You don't need to NAT to statefully allow inbound traffic. How the two became forever entangled is past me as technically depending what network you are sourcing from NAT doesn't actually prevent what you describe without also having the actual stateful firewalling enabled.
Taken another way: it's easier to statefully filter incoming flows (FW) than it is to statefully map flows (NAT) both from an implementation and operation perspective.
Can you explain what you mean with "It's destroyed the network functionality of mobile telecommunications"? Since I can think of exactly zero reasons one needs his handheld to be reachable from the Internet (that has not been long solved).
SIP and RTP are a pain. Long "fixed" but still a pain. ftp still refuses to die and is a pain in active mode. There are others.
Only yesterday I had to wheel out Wireshark to prove to a telephony services provider that their bod had forgotten to update a PBX with its changed WAN address.
https://myip.ms/info/ip_ranges_blocks/Major_Biggest_IP_Addre...