Update: Approaching IPv4 Run-out(ripe.net)
ripe.net
Update: Approaching IPv4 Run-out
https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/update-approaching-ipv4-run-out
139 comments
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:
https://auctions.ipv4.global/prior-salesw
It looks like the going rate per IP is between $20-$24 currently:
https://auctions.ipv4.global/prior-salesw
That's a good point...further scarcity will drive the prices to a point where selling is very attractive.
It's a big gamble on when to sell though. Eventually IPv6 adoption will hit a critical mass threshold and interest in paying for IPv4 IPs will dry up.
Has a date been set for when IPv4 will stop being routed?
No, because the Internet is a voluntary system.
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.
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.
Google is one of those influential companies and I could totally see them declaring that their crawler is going to stop visiting IPv4 after some date.
They would do that only once it costs them more money than they could make with the retrieved data. That's not going to happen anytime soon.
You might as well wonder whether google is actually going to stop crawling IPv6 addresses (are there any significant IPv6-only servers?)
You might as well wonder whether google is actually going to stop crawling IPv6 addresses (are there any significant IPv6-only servers?)
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.
ipv4 is the new bitcoin?
Don't know how credible it is, but these folks were predicting the current ~$20 price goes to ~$50 over a year's time:
Chart: https://www.retevia.net/wp-content/uploads/2019/02/IPv4-Pric...
Article: https://www.retevia.net/address-pricing-2019-and-beyond/
Chart: https://www.retevia.net/wp-content/uploads/2019/02/IPv4-Pric...
Article: https://www.retevia.net/address-pricing-2019-and-beyond/
Yeah, I think there will be a small bubble as some try and buy all they can while we continue to transition to ipv6
GE did the same thing. It sold 3.0.0.0/8 to amazon about a year ago.
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.
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.
Similar to eminent domain maybe.
Similar to eminent domain maybe.
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.
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.
Pretty sure that doesn't mean all distant API endpoints need ipv6 addresses.
Just means no hardcoded ipv4 or incompatible API calls. So that ipv6 to ipv4 gateways work.
So, the app is ready, but apple isn't dictating much about your backend.
Just means no hardcoded ipv4 or incompatible API calls. So that ipv6 to ipv4 gateways work.
So, the app is ready, but apple isn't dictating much about your backend.
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.
[1] https://en.wikipedia.org/wiki/Happy_Eyeballs
[1] https://en.wikipedia.org/wiki/Happy_Eyeballs
That can't be totally true, Twitter doesn't work on v6.
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).
[1] https://en.wikipedia.org/wiki/Happy_Eyeballs
[1] https://en.wikipedia.org/wiki/Happy_Eyeballs
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.
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.
> The gateway then NAT's all those mapped IPv6 addresses to it's IPv4 address.
Right, then its not a pure v6 network, its got v4 somewhere patched in. When I'm on my pure v6 network at home, Twitter does not work.
Right, then its not a pure v6 network, its got v4 somewhere patched in. When I'm on my pure v6 network at home, Twitter does not work.
And yet one of the largest UK ISP's by customer count (Virgin Media) still haven't managed to roll out DS-LITE ... 6 years after announcing it.
When I was at Cisco, I'm pretty sure my desk phone had a public IP.
In what, 1998? They have been on RFC1918 for like 20 years.
Source: Worked at Cisco.
Source: Worked at Cisco.
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.
There's apparently a wait list for /24's now. Desperation might inspire a new set of discussions.
I believe BGP tables are close to crossing a threshold. (768k entries) that breaks a bunch of routers, so they need to address that anyway.
I believe BGP tables are close to crossing a threshold. (768k entries) that breaks a bunch of routers, so they need to address that anyway.
We're already past 768k and are now around 800k[0].
[0] https://bgp.potaroo.net/as2.0/bgp-active.html
[0] https://bgp.potaroo.net/as2.0/bgp-active.html
There's another problematic threshold at 1024k.
HP have two contiguous class A 15 & 16 the latter was inherited when they took over DEC. That cant be justified.
IPv6 worldwide adoption is at just under 30%:
https://www.google.com/intl/en/ipv6/statistics.html
If the current growth rate continues, it looks like it will reach 100% by about 2035.
https://www.google.com/intl/en/ipv6/statistics.html
If the current growth rate continues, it looks like it will reach 100% by about 2035.
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...
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...
Wrong interpretation: the linked chart shows client-side adoption among Google users
In practice today IPv6 is a kind of high functionality NAT for consumer devices.
A more interesting statistic would be server-side adoption.
In practice today IPv6 is a kind of high functionality NAT for consumer devices.
A more interesting statistic would be server-side adoption.
"Google users" is approximately everybody, and surely client-side adoption is what drives server-side adoption?
If it’s not measured we don’t know
> "Google users" is approximately everybody
perhaps every 'body', but not at all every 'device'..
perhaps every 'body', but not at all every 'device'..
And more importantly, server-side adoption excluding Cloudflare, or at least a breakdown by IP and not by website.
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.
(Including, ahem, HN.)
(Including, ahem, HN.)
It's on our list. Hoping to get there soon.
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).
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.
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.
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.
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.
Would be more interesting if you net out mobile.
Would love to see the time slider on the per-country adoption map.
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.
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.
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.
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.
But there are secondary markets for IPv4, no?
https://duckduckgo.com/html?q=buy%20ipv4
Edit: And prices going up:
https://www.retevia.net/address-pricing-2019-and-beyond/
https://duckduckgo.com/html?q=buy%20ipv4
Edit: And prices going up:
https://www.retevia.net/address-pricing-2019-and-beyond/
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.
$ 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.
$ ip -4 addr show | grep eth0
# nothing
$ dig news.ycombinator.com AAAA +short
64:ff9b::d1d8:e6f0
$ wget -6 https://news.ycombinator.com -O /dev/null
Resolving news.ycombinator.com (news.ycombinator.com)... 64:ff9b::d1d8:e6f0
Connecting to news.ycombinator.com (news.ycombinator.com)|64:ff9b::d1d8:e6f0|:443... connected.
HTTP request sent, awaiting response... 200 OK
[...] ‘/dev/null’ saved [34663]
It's a translated with DNS64 ipv4 address into a NAT64 ipv6. They have 64:ff9b prefix.
Indeed it is, and it works fine. v4-only websites aren't a problem for running v6-only.
I am now at home and tried your experiment but I have IPv4 as well as IPv6.
The wget forced to v6 does not work here. That's a bug somewhere. My eyes are no longer happy 8( ... 8) ... ahh, all OK now!
The wget forced to v6 does not work here. That's a bug somewhere. My eyes are no longer happy 8( ... 8) ... ahh, all OK now!
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.
> I just wanted to make the point that v4-only websites are totally not a problem.
They will be once DoH breaks DNS64, unless Cloudflare invents a way to make it somehow work (perhaps hosting their own NAT64 gateway?).
They will be once DoH breaks DNS64, unless Cloudflare invents a way to make it somehow work (perhaps hosting their own NAT64 gateway?).
Since they seem to want to take over the internet, I guess that would be right up their street.
Clients can also synthesize the DNS64 records themselves locally, or use 464xlat.
Clients can also synthesize the DNS64 records themselves locally, or use 464xlat.
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?
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.
[1] http://www.litech.org/tayga/
[1] http://www.litech.org/tayga/
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]
[1] https://support.google.com/mail/answer/81126
[2] https://google.com/search?q=ipv6+gmail+ptr
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]
[1] https://support.google.com/mail/answer/81126
[2] https://google.com/search?q=ipv6+gmail+ptr
I think lots of these schemes use each /64 prefix as a single unit for reputation purposes.
With email deliverability the key factor is now domain name reputation and less ip.
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.
But alas, no, that's not the state of things.
But alas, no, that's not the state of things.
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.
sneak@nostromo-2:~$ host -t aaaa news.ycombinator.com
news.ycombinator.com has no AAAA record
sneak@nostromo-2:~$What's going on with IPv6 that is preventing it from alleviating the IPv4 scarcity?
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.
[0]: https://en.wikipedia.org/wiki/Link-local_address
[1]: Best doc I can find in 30 seconds that covers some of the differences: https://www.juniper.net/documentation/en_US/learn-about/ipv4...
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.
[0]: https://en.wikipedia.org/wiki/Link-local_address
[1]: Best doc I can find in 30 seconds that covers some of the differences: https://www.juniper.net/documentation/en_US/learn-about/ipv4...
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.
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.
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.
Personally I like the link local addresses, SLAAC, and NDP features.
IMHO, corporate IT: "what's the business case for this?".
It could be cheaper to buy IPv4 than have a company-wide (dual-stack?) IPv6 rollout:
* http://www.circleid.com/posts/20190815_the_2019_ipv4_market_...
It could be cheaper to buy IPv4 than have a company-wide (dual-stack?) IPv6 rollout:
* http://www.circleid.com/posts/20190815_the_2019_ipv4_market_...
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 an IT firm.
My boss: "why in the world would I figure out and enable ipv6 and have to configure everything twice and have twice the attack surface?"
Me: "umm... so that maybe 30 years in the future we can switch v4 off?"
It's a tough sell, even in IT :/ imo we should just plan time to do things properly instead of holding adoption back.
My boss: "why in the world would I figure out and enable ipv6 and have to configure everything twice and have twice the attack surface?"
Me: "umm... so that maybe 30 years in the future we can switch v4 off?"
It's a tough sell, even in IT :/ imo we should just plan time to do things properly instead of holding adoption back.
It's more complicated, it is often implemented poorly if at all, and it isn't really that necessary because of NAT/PAT.
The last one is starting to not be true, but it was a long, long, time getting here.
The last one is starting to not be true, but it was a long, long, time getting here.
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.
I'm not sure in what business area you are, but aren't domain names usually enough to abstract resolution from location?
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).
So when will HN and ycombinator.com get IPv6?
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.
Isn’t this just for free ipv4?
If you watch cloud providers ip spaces they are growing very impressively.
When people say ipv4 has run out they should qualify this as free IPv4
If you watch cloud providers ip spaces they are growing very impressively.
When people say ipv4 has run out they should qualify this as free IPv4
This is for unallocated IPv4. ISPs and cloud providers will still rent you an address for as long as you have money in the bank.
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.
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.
> The more ISPs migrate to IPv6 and CG-NAT, the more free IPv4 addresses for everyone else.
Uhhh, they're not returning their IPv4 addresses to any kind of free pool. Those IPs that they have allocated remain with them.
Uhhh, they're not returning their IPv4 addresses to any kind of free pool. Those IPs that they have allocated remain with them.
If they can make money selling them I don’t see that happening.
Current cost of an IPv4 address: $20
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.
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.
> dual stack IPv6+CG-NAT deployments should be the norm for many years to come
One can hope. I wouldn’t be too surprised if some ISPs try to deploy just CG-NAT and punt on IPv6 deployment as long as they can.
One can hope. I wouldn’t be too surprised if some ISPs try to deploy just CG-NAT and punt on IPv6 deployment as long as they can.
Supporting IPv6 natively would be cheaper as they'd need to invest less in NAT capacity.
They will more than make up the difference by increasing the rent for the public IPv4 addresses they got when they were still available.
Yeah, but it's not like offering IPv6 prevents those rents, so why waste that money on NAT capacity if they can pocket it instead?
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....
[0] https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual...
[0] https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual...
Because schools don't talk about IPv6 enough to make sysadmins and programmers comfortable with it, I think that's the root cause.
And not that it was a bad idea in the first place ?
[deleted]
RIPE, there's this story of The Boy Who Cried Wolf. Would suggest reading it.
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 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?
> all of them have announced the exhaustion of their pools of available address blocks of various sizes at various times over several years
AFRINIC has not exhausted IPv4 yet, although they are coming close to the beginning of the end (when they're down to their last /11).
AFRINIC has not exhausted IPv4 yet, although they are coming close to the beginning of the end (when they're down to their last /11).
> a lot of blocks to be returned to the pool
Nobody is returning addresses back to any pool. IPs are being allocated at a rate of over a million a month.
Nobody is returning addresses back to any pool. IPs are being allocated at a rate of over a million a month.
And cloud providers don't need IP addresses?
Not all of them: https://ipv6onlyhosting.com/en-us/cms/ipv6-shop/
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!
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.
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).
I'd like to be able to communicate with other handhelds without involving a STUN/TURN server, which is hugely unnecessary complexity.
What solution do you know for getting two clients behind CGNAT to talk to each other reliably, without relying on a third-party service?
Distributed applications and independence from monopolies that aggressively hoard and equally aggressively leak personal data.
NAT is annoying though
For what real world reasons?
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.
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.
Ah, the mythical "real world" where your concerns and requirements don't matter, and mine do.
Or having a similar conversation about ip v8
amazing?
https://myip.ms/info/ip_ranges_blocks/Major_Biggest_IP_Addre...