Amazon, Verizon found using IPv4 240/4 addresses(labs.ripe.net)
labs.ripe.net
Amazon, Verizon found using IPv4 240/4 addresses
https://labs.ripe.net/author/qasim-lone/2404-as-seen-by-ripe-atlas/
147 comments
How can it leak when they only use it internally? They would have to announce this IP range specifically through BGP et al, which I can only assume would raise some serious questions, given that they cannot possibly be the official owner of this range?
On the other hand, that’s probably how we ended up with this article. I still don’t understand how this could have been an accident though.
On the other hand, that’s probably how we ended up with this article. I still don’t understand how this could have been an accident though.
No, these are being found in traceroutes. Any time you end up being routed over a private network you can end up with private non-announced IP addresses being present in said traceroute - seeing 10.x.x.x addresses in the middle of traceroutes is something you will see occasionally as well. When the TTL expires and the router sends the TTL exceeded message back, it has to select SOMETHING for the source IP address, and there's nothing to prevent that choice being the internal IP address it uses.
By the way, "found using" might sound like someone is angry at the companies for doing this, but the article doesn't criticize them. Some people do find it objectionable, but my focus would be on accelerating coordination about the use of 240/4 addresses, so people can agree on what behavior to expect.
(I'm the first author of a current draft about that, https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas..., and I contributed to this RIPE Labs article but didn't do the underlying research.)
(I'm the first author of a current draft about that, https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas..., and I contributed to this RIPE Labs article but didn't do the underlying research.)
This seems like a rather long post for the equivalent of "haha, I can see your underpants." What's the real significance to this vs seeing 10/8 show up in a traceroute?
The article discusses a 2007 proposal [1] for 240/4 to be used as a private address space -- essentially a bigger, alternative to 10/8 -- and then goes on to imply/state that the proposal failed as it was felt that adding further sticking plasters to IPv4 was somehow undermining IPv6 adoption. The point of the article seems to be to show that in reality, 240/4 is being used as a private address space despite not being officially sanctioned as such.
As I think you're pointing out, that's not necessarily interesting because if 240/4 were officially sanctioned as private space, then these people would likely not want to use it, for the same reasons that they aren't already using 10/8.
[1] https://datatracker.ietf.org/doc/html/draft-wilson-class-e-0...
As I think you're pointing out, that's not necessarily interesting because if 240/4 were officially sanctioned as private space, then these people would likely not want to use it, for the same reasons that they aren't already using 10/8.
[1] https://datatracker.ietf.org/doc/html/draft-wilson-class-e-0...
There are a bunch of users for whom 10/8 is insufficiently large, but 240/4 is big enough.
I suspect both AWS and Verizon fall into that category.
I suspect both AWS and Verizon fall into that category.
If such huge companies who has both the need and the resources to use ipv6 internally would rather stick to 240/4 or 10/8 ipv4, what hope do smaller organizations have of adopting ipv6?
I chased ipv6 hard for a while. Concluded not worth it. Do a fan of proposals to inch up address space in various ways
If you're using addresses in the 240/4 block, you're going to run into issues when/if those addresses are assigned for public use.
It's not necessarily a problem for the general public, but will pose a routing problem for those using them internally.
It's not necessarily a problem for the general public, but will pose a routing problem for those using them internally.
People have been privately squatting on public networks like 11/8 since forever. It's a problem for them, maybe, and a mild curiosity for the rest of us. I'm just saying "we saw 240 in a traceroute" could have been a tweet, not a research paper. I kept scrolling and scrolling trying to find out why it wasn't a tweet.
One of our clients used to have a sysadmin with a knack for 192.169/16. Haven't had any problems yet but its bound to happen eventually.
I personally love IP addresses in the 172.16/12 range. I have my house in that range, and I can VPN in from anywhere and never have any IP address conflicts.
EDIT: I just realized you said 192.169/16, which is definitely not available for private IPs.
EDIT: I just realized you said 192.169/16, which is definitely not available for private IPs.
I talked to someone who had to re-ip his home network because he was using a subnet of 10./8 that conflicted with his VPN/work access. It's still possible to conflict with a local network you're on, it's not that nobody ever uses a 172.16/12 block.
A company I worked for, which is basically a group of a dozen acquisitions, uses practically every RFC1918 block which makes things really annoying. 10./8 used by IT, 192.168/16 used by company X acquired in 2004, 172.17/16 used by company Y acquired in 2011. The list of routes the VPN software installed was impressive.
A company I worked for, which is basically a group of a dozen acquisitions, uses practically every RFC1918 block which makes things really annoying. 10./8 used by IT, 192.168/16 used by company X acquired in 2004, 172.17/16 used by company Y acquired in 2011. The list of routes the VPN software installed was impressive.
I think if I were VPNing from a campus or an office, things would be different. Hotels, coffee shops, and corporate guest networks all seem to either like 10/8 or 192.168/16.
By the way, I use 172.30/16 for my home net. I have personally seen use of 172.16/16 and 172.31/16 before.
By the way, I use 172.30/16 for my home net. I have personally seen use of 172.16/16 and 172.31/16 before.
I work for a place that legitimately has 192.16.64.0/21, it's caused occasional confusion when folks aren't looking really closely.
Hey... I have an address in that block... >:[
That addr rings a bell.. Is it owned by github by any chance?
VPN services[1] seem to love assigning non-compliant addresses like 5/8 or 100/8 for their internal networks.
[1] and I mean 'real' VPN that connect machines you own, not glorified proxies/exit nodes.
[1] and I mean 'real' VPN that connect machines you own, not glorified proxies/exit nodes.
Amazon was definitely using 11/8 internally when I was there 7 years ago.
These are being used as link addresses, they probably aren't even routable within Amazon's network. They probably want the link addresses to be globally unique so it simplifies management or so traceroute reverse lookup is easier (e.g. to pinpoint traffic loss). They probably ran out of the other RFC3330 usual suspects or something.
I wouldn't read too much into it. If they are using it in a way that will break if 240/8 is assigned, I'm sure they will fix it quickly.
I wouldn't read too much into it. If they are using it in a way that will break if 240/8 is assigned, I'm sure they will fix it quickly.
Why wouldn't they use IPv6 for that? Compatibility issues?
Yeah, I don't know how many routers support RFC 5549 and it never seemed to become a best practice.
I think the thing is that if you actually need only 24ish bits worth of addresses for something and it doesn't need to be routable, ipv6 just adds a lot of baseline complexity ipv4 doesn't have unless you go out of your way. Ipv6 isn't just an address extension, it's a whole ass architecture unto itself.
The current IETF notion seems to be that any decision on 240/4 will hinder IPv6 adoption, they are very unlikely to do anything with it. This ironically means 240/4 ends up de facto private...
* See https://news.ycombinator.com/item?id=29246420 for a discussion of a related proposal.
* See https://news.ycombinator.com/item?id=29246420 for a discussion of a related proposal.
Tell that to China who internally are apparently using all kinds of unusable addresses due to the The Great Firewall!
That's how I'm reading it too. "IPv4 addresses are scarce and networks play dirty tricks to make things work, news at 11!" We know, folks. IPv4 is awful for network operators in the modern Internet of Way Too Many Things. Let them have their tricks.
I know multiple large companies that would have no choice but to block any public use of these, as they have databases where these addresses have special meaning.
Yes, obviously that was a terrible choice to make. But it's there. And legal compliance means they can't just let these addresses in as normal unicast.
So while these can work as rfc1918 and similar, nobody will ever want to use these on publicly facing clients or servers. Too many places will never support them.
I'd rather be behind 3 layers of CGNAT.
Yes, obviously that was a terrible choice to make. But it's there. And legal compliance means they can't just let these addresses in as normal unicast.
So while these can work as rfc1918 and similar, nobody will ever want to use these on publicly facing clients or servers. Too many places will never support them.
I'd rather be behind 3 layers of CGNAT.
Plus there's tons of legacy equipment that simply won't work with 240/4. It will be a support nightmare. Arguably, opening up 240/4 could've been done around the time we started rolling out IPv6... It's a bit late now.
Presumably when IPv6 was being rolled out the intent was to actually move to IPv6 instead of trying to keep IPv4 on life support indefinitely...
I guess the big companies are not really keen to move to IPv6, since they control large swaths of IPv4 territory anyway. And only they would have the power to initiate a move, so i guess we are stuck in somewhat of a limbo here…?
The thing about IPv6 is it has significant switching costs but almost no benefit to end users. The exception, I guess, is network providers who are struggling with a shortage of v4 addresses.
We've been trying to get people to switch since the late 90s/early 00s. And it's only now making progress because IPv4 address have an actual cost which keeps increasing.
But I think IPv6 is huge example of second system syndrome. Instead of just solving the obvious and most important problem of IP address exhaustion, we piled on a whole bunch of other requirements, greatly expanding the scope, increasing switching cost, and dragging out the migration for literal decades. Here we are 20+ years later with only 40% adoption of IPv6...
And I can see the temptation to bundle in all those other changes, since this might be the big opportunity to get them out there. But seems like we could have come up with a simpler and easier to switch to alternative that would have solved the acute issue much faster.
Instead we're here muddling through.
We've been trying to get people to switch since the late 90s/early 00s. And it's only now making progress because IPv4 address have an actual cost which keeps increasing.
But I think IPv6 is huge example of second system syndrome. Instead of just solving the obvious and most important problem of IP address exhaustion, we piled on a whole bunch of other requirements, greatly expanding the scope, increasing switching cost, and dragging out the migration for literal decades. Here we are 20+ years later with only 40% adoption of IPv6...
And I can see the temptation to bundle in all those other changes, since this might be the big opportunity to get them out there. But seems like we could have come up with a simpler and easier to switch to alternative that would have solved the acute issue much faster.
Instead we're here muddling through.
As soon as adoption starts hitting 80%, lazy sysadmins won't bother setting up ipv4 support, and suddenly the ipv4 internet will get less useful, and things will snowball to IPv6 (in public at least - I'm sure internal company LAN's will remain IPv4 behind a proxy for decades more).
To get from 40%to 80% just requires a few ISP's to make it the default on their routers, which they have an incentive to do as soon as they run out of IP's and CGNAT starts to get expensive to run. Enabling IPv6 immediately halves the load on the CGNAT boxes because all the CDN traffic immediately uses IPv6.
To get from 40%to 80% just requires a few ISP's to make it the default on their routers, which they have an incentive to do as soon as they run out of IP's and CGNAT starts to get expensive to run. Enabling IPv6 immediately halves the load on the CGNAT boxes because all the CDN traffic immediately uses IPv6.
> To get from 40%to 80% just requires a few ISP's to make it the default on their routers
What you mean? I think what's needed is IPv6 support by ISP and make Happy Eyeballs on client to strongly prefer IPv6, not router.
What you mean? I think what's needed is IPv6 support by ISP and make Happy Eyeballs on client to strongly prefer IPv6, not router.
> I'm sure internal company LAN's will remain IPv4 behind a proxy for decades more
IPv4 will continue to exist in limited capacity as long as network hardware supports it. With increasingly more network hardware suppliers phasing out IPv4 support for cost reasons, we will see it dying quickly.
IPv4 will continue to exist in limited capacity as long as network hardware supports it. With increasingly more network hardware suppliers phasing out IPv4 support for cost reasons, we will see it dying quickly.
Internal company LANs will never switch, both for cost reasons and because IPv6's addressing choices are badly suited for it. Maybe one day companies will abolish the internal LAN and move to zero-trust, but until they do IPv4 will stay. That's a big enough market to be supported indefinitely.
> The thing about IPv6 is it has significant switching costs but almost no benefit to end users.
Real scenario - developer of Valheim initially released the game on Itch.io but then removed it from there, saying that it now has to rely on Steam services for NAT traversal for its multiplayer, making it tied to Steam in result.
Clearly if IPv6 would have been available there wouldn't have been the need for such services, no? So I'd say end users are bitten by this, just not in obvious ways for them to start complaining about it.
Real scenario - developer of Valheim initially released the game on Itch.io but then removed it from there, saying that it now has to rely on Steam services for NAT traversal for its multiplayer, making it tied to Steam in result.
Clearly if IPv6 would have been available there wouldn't have been the need for such services, no? So I'd say end users are bitten by this, just not in obvious ways for them to start complaining about it.
> Clearly if IPv6 would have been available there wouldn't have been the need for such services, no?
The additional benefit of those services is that they mask clients' IP addresses. This makes doxxing and DDoS attacks much hard to achieve.
Grand Theft Auto 5 Online is notorious for its direct peer to peer connectivity, to the point where it's recommended to play with a VPN. Playing without one exposes you to a very real risk of being hit with a DDoS attack launched by a cheater (or someone with the basic knowledge of Wireshark) who wants to take revenge for one reason or another.
DDoS services are a commodity accessible to anyone with a $5 gift card these days. I don't want to go back to the world of direct peer to peer connections for gaming.
The additional benefit of those services is that they mask clients' IP addresses. This makes doxxing and DDoS attacks much hard to achieve.
Grand Theft Auto 5 Online is notorious for its direct peer to peer connectivity, to the point where it's recommended to play with a VPN. Playing without one exposes you to a very real risk of being hit with a DDoS attack launched by a cheater (or someone with the basic knowledge of Wireshark) who wants to take revenge for one reason or another.
DDoS services are a commodity accessible to anyone with a $5 gift card these days. I don't want to go back to the world of direct peer to peer connections for gaming.
Could be, that that's unrelated to IPv6, so a totally different issue.
Instead of NAT traversal IPv6 is going to require firewall traversal.
Absolutely. I'll say it again and again, I like NATs, especially for home setups. They help hiding devices from the public that never need to be accessible outside of a LAN. And you can never trust home router firewalls to be configured correctly. If all devices had their unique IP address, we'd see much larger botnets out there.
If your router's firewall is set to not allow incoming traffic to an IP behind it, then the IP isn't going to be accessible, and it doesn't matter who knows the IP. This is much simpler than NAT.
Your device also isn't hidden too much if a NAT router lets it have the ability to make outgoing connections - it's just less convenient to access.
You might see more attacks targeting specific internal IPs if NAT never existed more but it doesn't necessarily follow that NAT is preventing or reducing botnets. Dos/DDoS attacks can be focused a your router with or without NAT.
Your device also isn't hidden too much if a NAT router lets it have the ability to make outgoing connections - it's just less convenient to access.
You might see more attacks targeting specific internal IPs if NAT never existed more but it doesn't necessarily follow that NAT is preventing or reducing botnets. Dos/DDoS attacks can be focused a your router with or without NAT.
You don't need any traversal services for that though. You can set up port forwarding as needed on you router if something requires special access.
Problems start with NATs that you can't control.
Problems start with NATs that you can't control.
IPv6 space is too big to scan, a /64 network is already a big problem. Botnets require vuln device to have internet connectivity, they don't need to have inbound connections. Most of them use udp/dns etc. for control.
IP address exhaustion isn't the only issue - subnetting was never meant to be as complex as it is. End users shouldn't care about addresses. Optimally you shouldn't be specifying raw Ip addresses anywhere. It's why we have DNS and discovery protocols. IPv6 helps this. It drastically simplifies subnetting and eliminates the need for NAT.
IPv6 does neither in most cases unfortunately.
IPv6 could blow routing tables sky high.
We burn 64 bits of the space (!!) on the "privacy extensions" changing part of ipv6 which is totally insane, and so you have a constant churn for 64 bits of the space. This churn complicates a fair bit of local area network address use.
You can get a static IPv4 block if you need it with business class service as well for that site. Despite claims it's a total pain to get IPv6 static blocks assigned by ISPS.
Your internal network can be subnetted however you like if you do any site to site VPN if using NAT. you are not dependent on uplinks at all.
Now if you have a business with a bunch of sites, not all may have full BGP etc setups. For example, you might do a dual WAN link - one fiber at 1gbps, another at 300mbps for backup. This is seamless with IPv4 in most cases.
With IPv6 - if your routes flap, you have to readdress everything on your entire network (!!!) for that site. And these updates are SLOWER and worse from what I've seen then WAN failover on the NAT. So then you can try to do the workarounds (network prefix stuff). So if you flap around a bit the network is done. This could just be a tech reconfiguring things and pulling a cable and putting it back in seconds later.
And the list goes on. Network prefix stuff is poorly supported. You are basically forced into dual stack mode. Etc.
IPv6 could blow routing tables sky high.
We burn 64 bits of the space (!!) on the "privacy extensions" changing part of ipv6 which is totally insane, and so you have a constant churn for 64 bits of the space. This churn complicates a fair bit of local area network address use.
You can get a static IPv4 block if you need it with business class service as well for that site. Despite claims it's a total pain to get IPv6 static blocks assigned by ISPS.
Your internal network can be subnetted however you like if you do any site to site VPN if using NAT. you are not dependent on uplinks at all.
Now if you have a business with a bunch of sites, not all may have full BGP etc setups. For example, you might do a dual WAN link - one fiber at 1gbps, another at 300mbps for backup. This is seamless with IPv4 in most cases.
With IPv6 - if your routes flap, you have to readdress everything on your entire network (!!!) for that site. And these updates are SLOWER and worse from what I've seen then WAN failover on the NAT. So then you can try to do the workarounds (network prefix stuff). So if you flap around a bit the network is done. This could just be a tech reconfiguring things and pulling a cable and putting it back in seconds later.
And the list goes on. Network prefix stuff is poorly supported. You are basically forced into dual stack mode. Etc.
Queue the million network admins complaining about how IPv6 addresses are hard to memorise. Meanwhile mucking about with IP addresses manually is an IPv4 problem that the automation of IPv6 largely eliminated.
“Show me how your new system solves problems only the old system has, or I won’t adopt it!”
“Show me how your new system solves problems only the old system has, or I won’t adopt it!”
If memory serves me right, one of the biggest selling points for IPv6 to end users (at the time) was it's "built in" support for IPsec (ESP and AH are standard extensions in the protocol). These days I'm not sure how beneficial something like this would be, Wireguard outperforms it AFAIK.
That whole thing was kind of a lie since you can't force hosts to implement IPSec and IPSec was immediately backported to IPv4 anyway.
> significant switching costs
but you don't have to switch, you can have both at once.
but you don't have to switch, you can have both at once.
Which costs even more.
not really. turning off ipv4 on a given network would cost approximately nothing. having ipv4 while you bring up ipv6 lets you learn as you go and adapt as you learn, and is of value. there doesn’t even need to be a cutover, they coexist.
its not even like there is a significant hardware cost; all network gear for the past 15+ years has supported ipv6; you get it for free when you buy hardware that works with ipv4.
its not even like there is a significant hardware cost; all network gear for the past 15+ years has supported ipv6; you get it for free when you buy hardware that works with ipv4.
I kind of wonder if it would be worth making an ipv7 that is less ambitious than ipv6, and focuses on having an easier upgrade path from ipv4. But then we would have three competing standards...
Causes all kinds of issues with people’s consciousness becoming digital.
Source: Serial Experiments Lain
Source: Serial Experiments Lain
I’ve advocated for this as well and find it a surprisingly unpopular opinion on HN.
I think you're confusing "unpopular" with "technically impossible".
It's far too late for that. We'll be stuck with dual-stack for a long time.
Yeah, it might have been a good idea 15 years ago or so, when adoption was low and it was apparent that the switch wasn't happening fast enough, but now ipv6 is used enough that introducing yet another version of ip will just make things worse.
It doesn't look stuck to me.
https://www.google.com/intl/en/ipv6/statistics.html
That's end user/website visitor adoption rates, but website adoption rates are much different. Since 2016, the share of end users with ipv6 support has quadrupled from 11% to the current 40%. For websites, if you look at the Alexa top 500 from 2016 and compare it with today, you actually see a regression for the "site answers ipv6" column from 95 to 86, while the "www. site answers ipv6" column had a slight increase from 108 to 111.
ISPs are way more eager to move to ipv6, probably due to a higher ip address per customer ratio than companies that offer network services like websites or such.
http://www.delong.com/ipv6_alexa500.html
http://web.archive.org/web/20161019011050/http://www.delong....
ISPs are way more eager to move to ipv6, probably due to a higher ip address per customer ratio than companies that offer network services like websites or such.
http://www.delong.com/ipv6_alexa500.html
http://web.archive.org/web/20161019011050/http://www.delong....
Not stuck, but hardly a runaway success. That graph shows adoption at 40% and increasing, roughly linearly, at maybe 5% a year. At this rate, it's going to be 2040-2050 before we are in any realistic position for an IPv4 switchoff.
So: IPv4 space already pushing $50/address, ~$1bn of unused-but-potentially-routable IPv4 space (240/4) just sitting there, and 25 years to go before it becomes worthless. Any guesses what happens next?
So: IPv4 space already pushing $50/address, ~$1bn of unused-but-potentially-routable IPv4 space (240/4) just sitting there, and 25 years to go before it becomes worthless. Any guesses what happens next?
Relevant:
“When will >50% of users access Google over IPv6?”
Community Prediction Dec 21, 2024 at https://www.metaculus.com/questions/9558/when-50-of-users-ac...
“When will global IPv4 traffic account for less than 1% of total internet traffic?”
Community Prediction Sep 23, 2042 at https://www.metaculus.com/questions/4449/when-will-global-ip...
“When will >50% of users access Google over IPv6?”
Community Prediction Dec 21, 2024 at https://www.metaculus.com/questions/9558/when-50-of-users-ac...
“When will global IPv4 traffic account for less than 1% of total internet traffic?”
Community Prediction Sep 23, 2042 at https://www.metaculus.com/questions/4449/when-will-global-ip...
That's just the path from the user to the gateway (usually a CDN, rarely the server where a website is hosted). Behind that, pretty much all is IPV4. And there's not reason to change, very few companies exhaust the private address range. But as long as everything behind the first gateway remains ipv4, sysadmins will mostly work with ipv4 and ipv6 will never make a real breakthrough.
I believe even in 10 or 20 years, we'll see ipv6 only on public traffic, anything else (which is much more both in traffic and ips) will remain on ipv4.
I believe even in 10 or 20 years, we'll see ipv6 only on public traffic, anything else (which is much more both in traffic and ips) will remain on ipv4.
Interesting. There seems to be a spike around Christmas every year; I wonder if that's due to more people using phones rather than computers during holidays? Or the mix of Asian vs European/American traffic changes?
There also seems to be some sort of weekday/weekend pattern going on.
There also seems to be some sort of weekday/weekend pattern going on.
Both are explained by workplaces being slower to adopt IPv6.
Thank you thats very interesting!
Why does India have such a large adoption rate? Because the got newer hardware to start with I guess?
Why does India have such a large adoption rate? Because the got newer hardware to start with I guess?
Simply because India has huge amounts of mobile devices, and the Indian ISPs didn't get assigned many IPv4 gold rush days when anyone could get an addresses by asking.
Instead they've aggressively rolled out IPv6 and carrier grade NAT where needed
Instead they've aggressively rolled out IPv6 and carrier grade NAT where needed
Seems like that's mostly mobile users[1], even in the US the mobile carriers are all IPv6, unlike most residential ISPs...
1: https://www.businesstoday.in/technology/story/india-to-have-...
1: https://www.businesstoday.in/technology/story/india-to-have-...
The question is why China is so low. They must have close to a billion mobile devices only at any time. Other countries aggressively use ipv6 for those, I'm surprised China doesn't. Or Google just doesn't see the real traffic in China?
We had some customers in india that required ipv6 support bc some indian isps are apparently ipv6 only!
only 40% adoption after 25 years, that's stuck to me.
I wouldn't say stuck...
The adoption rate in August 2021 was 35.26%, August this year is 39.71% thats a reasonable 12 month growth of 12.6%.
Between August 2020(33.24%) and August 2021(35.26%) there was a 12 month growth of 6%.
Adoption velocity is increasing year on year and for much of the past 25 years there was little reason to roll out IPv6 with gusto and so telcos didn't bother with the investment. With the exhaustion of cheap IPv4 we should see IPv6 adoption velocity only increase.
The adoption rate in August 2021 was 35.26%, August this year is 39.71% thats a reasonable 12 month growth of 12.6%.
Between August 2020(33.24%) and August 2021(35.26%) there was a 12 month growth of 6%.
Adoption velocity is increasing year on year and for much of the past 25 years there was little reason to roll out IPv6 with gusto and so telcos didn't bother with the investment. With the exhaustion of cheap IPv4 we should see IPv6 adoption velocity only increase.
If a user has capability for both(I think most?), is IPv6 preferred?
Yes. IPv4 connections are only attempted after a small delay: https://en.m.wikipedia.org/wiki/Happy_Eyeballs
Amazon and Verizon definitely don't have as many IPs as they want or need.
Other clouds too.
And CGNAT is expensive. No. There are some legacy allocations, but at least my experience is than nobody has enough.
Other clouds too.
And CGNAT is expensive. No. There are some legacy allocations, but at least my experience is than nobody has enough.
I think they're waiting for ipv8, as I am, which is really just an extra octlet at the start of the IPv4 block.
ipv6 is windows me. Skip over it. Wait for ipv8.
edit: Oh! We could make ivp8 just 16bit instead of an octlet!
ipv6 is windows me. Skip over it. Wait for ipv8.
edit: Oh! We could make ivp8 just 16bit instead of an octlet!
I have occasionally wondered about this, specifically from a human factors point of view. I recall an exercise a professor conducted in my intro to psych course as an undergraduate. Try to remember and recall this sequence of numbers:
1...7...7...6...1...8...1...2...1...8...6...5...1...9...1...8...1...9...4...5
And then try to remember and recall this sequence:
1776...1812...1865...1918...1945
Pretty much everyone finds the latter easier even though they are effectively equivalent. This was done as a demonstration of Miller's 7+-2 model of working memory.
I sometimes wonder if the reason IPv4 continues to stick around and IPv6 hasn't gotten the uptake we need is because the former fits into the memory models needed by the end users (developers) whereas a space of 2^128 instead of 2^32 starts pushing the boundary of what a human operator can easily keep in memory.
1...7...7...6...1...8...1...2...1...8...6...5...1...9...1...8...1...9...4...5
And then try to remember and recall this sequence:
1776...1812...1865...1918...1945
Pretty much everyone finds the latter easier even though they are effectively equivalent. This was done as a demonstration of Miller's 7+-2 model of working memory.
I sometimes wonder if the reason IPv4 continues to stick around and IPv6 hasn't gotten the uptake we need is because the former fits into the memory models needed by the end users (developers) whereas a space of 2^128 instead of 2^32 starts pushing the boundary of what a human operator can easily keep in memory.
I mean, those numbers would be significant to an American with some grasp of history. That doesn't seem like the same thing as memorizing 5 random 4 digit numbers.
I agree though that IPv6 has some human factor problems. You can actually use IPv4 addresses in it like ::10.0.0.1 - that's valid IPv6 if you wanted to use it on your own networks at least.
I agree though that IPv6 has some human factor problems. You can actually use IPv4 addresses in it like ::10.0.0.1 - that's valid IPv6 if you wanted to use it on your own networks at least.
Sure, this was a class at an American university, the context of those particular numbers is important as an example, but the exercise likely transfers to other relevant dates in other countries. At the core of it though is that arguably there are IPs (numbers) in any org that might be worth committing to memory because systems can and do fail, and for humans it seems to me that encoding IPv4 is inherently easier than encoding IPv6. My (untested) hypothesis is that this may be at least somewhat of a contributing factor to the slowness of IPv6 adoption (IMO the other more prevalent one being the market factors re. IPv4 scarcity). I just thought it was an interesting parallel to share.
Interesting reference I'm not sure though how many people actually keep IP addresses in their memory. Even with IPv4 I usually copy paste the entire address unless I'm sure only one of the octets have changed. I wonder if others do the same.
I did phone support for a dial-up ISP 20 years ago. I can still remember their IP for www., as well as ns1. and ns2.
And I’ll probably take the root password to their RADIUS server to my grave.
And I’ll probably take the root password to their RADIUS server to my grave.
For ipv4, i will often memorize an address for short periods of time, to type them in somewhere else, or to be able to recognize a particular address in logs or something.
With ipv6, that's less doable.
With ipv6, that's less doable.
I only remember the last 2 octets since we own the entire 132.20 space and most 131 and 132 in general for my job.
Once you make any change, even just "add another octet", you're into the chicken and egg problem IPv6 faced until recent years forced the hands of some ISPs. Given that IPv6 now has something like 20% adoption, there's little point starting over with something people view as simpler because of smaller changes to the written representation of addresses.
There is alot more changes then just an expanded space with ipv6
So while you may have a similar problem it would be FAR FAR FAR FAR easier for organizations to adopt an addressing system that works EXACTLY the same as ipv4 just with a larger address space
then all the other "improvements" they are forcing down everyone network (unwanted) in with ipv6
ipv6 spec caused all the problems by biting off more than what was needed to solve the problem.
So while you may have a similar problem it would be FAR FAR FAR FAR easier for organizations to adopt an addressing system that works EXACTLY the same as ipv4 just with a larger address space
then all the other "improvements" they are forcing down everyone network (unwanted) in with ipv6
ipv6 spec caused all the problems by biting off more than what was needed to solve the problem.
I mean, we could do something similar with ipv6.
Just start with 1::a: for the first 96 bits and duplicate the entire ipv4 range into the remaining sections (I.e. 8.8.8.8 would become 1::a:8:8:8:8) which would still leave a huge amount of space open from a's-f's being technically available as identifiers (i.e. 1::a:8:8:8:f would be a valid ipv6 address).
Then, as people stop using NAT, let them have access to the 1::b: section, and if that section ever gets filled, 1::c:, etc. Once NAT is sorted, roll out routers that would NAT ipv4 to 1::b: addresses so that they are in both locations at the same time.
It's easy enough to mentally switch to using colons instead of periods, and everyone could also easily memorize their opening "street sign" or whatever it is called.
Just start with 1::a: for the first 96 bits and duplicate the entire ipv4 range into the remaining sections (I.e. 8.8.8.8 would become 1::a:8:8:8:8) which would still leave a huge amount of space open from a's-f's being technically available as identifiers (i.e. 1::a:8:8:8:f would be a valid ipv6 address).
Then, as people stop using NAT, let them have access to the 1::b: section, and if that section ever gets filled, 1::c:, etc. Once NAT is sorted, roll out routers that would NAT ipv4 to 1::b: addresses so that they are in both locations at the same time.
It's easy enough to mentally switch to using colons instead of periods, and everyone could also easily memorize their opening "street sign" or whatever it is called.
This mapping of the IPv4 address space into IPv6 already even exists, in the ::ffff::<ip v4 address> range.
e.g. ::ffff::192.168.1.1
is an IPv6 representation of 192.168.1.1
Or in more standard v6 notation
0000:0000:0000:0000:0000:ffff:c0a8:0101
e.g. ::ffff::192.168.1.1
is an IPv6 representation of 192.168.1.1
Or in more standard v6 notation
0000:0000:0000:0000:0000:ffff:c0a8:0101
It's easy to start with.
Phase one has us use something in tcp headers, maybe something in the reserved area, to set a number. It's OK for that to just be maybe 1 to 4 even, or something small depending upon bit size requirements.
Since old systems won't use that reserved header space to determine anything, they'll ignore it. And new systems will exclusively use unroutable address space, like 240 being discussed here, for routing.
So old systems will drop the 240/ address space, but new systems will route it, as it will be 2.240.x.x.x. So only compliant systems will see the new address space ; the rest won't.
It won't help old systems, but it will mean new systems only using old address space, can speak to old systems, without breaking them.
Everyone loves sensible change, so unlike ipv6, ipv8 will only take 20 years! (What's ipv6 been out for, 25 years and not adopted yet?)
Phase one has us use something in tcp headers, maybe something in the reserved area, to set a number. It's OK for that to just be maybe 1 to 4 even, or something small depending upon bit size requirements.
Since old systems won't use that reserved header space to determine anything, they'll ignore it. And new systems will exclusively use unroutable address space, like 240 being discussed here, for routing.
So old systems will drop the 240/ address space, but new systems will route it, as it will be 2.240.x.x.x. So only compliant systems will see the new address space ; the rest won't.
It won't help old systems, but it will mean new systems only using old address space, can speak to old systems, without breaking them.
Everyone loves sensible change, so unlike ipv6, ipv8 will only take 20 years! (What's ipv6 been out for, 25 years and not adopted yet?)
Rather than changing TCP, we could just make web browsers query SRV records to see what port to connect to. Then you could host 65535 websites on the same IP address, without requiring any software in the middle to check Host/ALPN/SNI. (The web is moving to UDP anyway with HTTP/3. Not saying the web is the only important part of the Internet, but it's a big one.)
IPv6 is kind of over the major adoption hurdle of rewriting all software to understand it. Nearly all software understands it. I'm not sure anyone really has the appetite for that again.
IPv6 is kind of over the major adoption hurdle of rewriting all software to understand it. Nearly all software understands it. I'm not sure anyone really has the appetite for that again.
People like to make fun of ipv6 adoption rates but I'm pretty sure we'll all be dead and dust before srv becomes much more than a niche curiosity. It has similar chicken and egg problems but much less financial motivation behind it.
SRV for HTTP maybe. But SRV for email autoconfig, IM applications, game servers etc. is already here
Honestly, if IPV6 had been v4 but with 2 extra octlets, I believe we would be at close to 100% adoption. And also wouldn't run out of ips anytime soon.
They haven't done many of the changes for fun but because it makes some things work better i.e. using multicast instead of a broadcast in many places compared to IPv4. Enabling and making autoconfiguration a lot more integral. Making the smallest standard prefix /64 (with P2P being /127) - eliminating basically all thinking about how many hosts can I fit in a subnet.
There are things with MTU and fragmenting that are partially more complicated but in a sense also simpler than IPv4.
haha, oh man you had me going there for a second.
I've been thinking, we really just need lots and lots and lots of IP addresses, far more than we realise right now. ipv8? Should probably be ipv32 or some such.
An example ; when we start throwing smart nano on the grass, to see how each blade of grass is doing on your lawn. Well, each nano is going to need an IP address, and so will all in the neighbourhood. And that's just the grass.
What about when some scientist wants to track sand dispersal patterns, on a beach, after a hurricane? And wants to have each grain of sand tagged with its own nano hitchhiker? Just think of the IP addresses we'll need then!
And even medicine. What if we want to interally tag each cell in our bodies with nano? What if we want to bioengineer our body, so that each cell has its own IP address? And can report health/condition?
No, we need more, more more IP addresses! So many more.
An example ; when we start throwing smart nano on the grass, to see how each blade of grass is doing on your lawn. Well, each nano is going to need an IP address, and so will all in the neighbourhood. And that's just the grass.
What about when some scientist wants to track sand dispersal patterns, on a beach, after a hurricane? And wants to have each grain of sand tagged with its own nano hitchhiker? Just think of the IP addresses we'll need then!
And even medicine. What if we want to interally tag each cell in our bodies with nano? What if we want to bioengineer our body, so that each cell has its own IP address? And can report health/condition?
No, we need more, more more IP addresses! So many more.
> What if we want to interally tag each cell in our bodies with nano?
There will need to be multiple addresses for all the nano-services running inside each of those nanobots. Solution: install a k8s cluster with each nano...
There will need to be multiple addresses for all the nano-services running inside each of those nanobots. Solution: install a k8s cluster with each nano...
Yes or install a main router/access point for each human that sub-adresses all nanobots. Or do you want them exposed to the broader internet?
I mean, IPv6 is a lot of addresses:
https://www.techtarget.com/whatis/feature/IPv6-addresses-how...
https://www.techtarget.com/whatis/feature/IPv6-addresses-how...
This part really drives it home:
"[...] assign an IPV6 address to EVERY ATOM ON THE SURFACE OF THE EARTH, and still have enough addresses left to do another 100+ earths."
"[...] assign an IPV6 address to EVERY ATOM ON THE SURFACE OF THE EARTH, and still have enough addresses left to do another 100+ earths."
Well, IPv6 has 128 bits, so 3,4 x 10^38 adresses. Surface area of the Earth: 5,1 x 10^14 m2. Maybe adressing grass blades could be possible with IPv6.
It's something like a /48 for each second m^2 of Earth's land surface. Single addresses are not a useful metric, as IPv6 works a lot more with prefixes (groups of addresses, to simplify management and allow things like auto-configuration). The smallest prefix that you would assign to a VLAN with auto-configuration is /64. So /48 (or 65 536 subnets) in IPv6 would be the equivalent of /16 (like 192.168.X.X but global unicast) in IPv4. That is what normal businesses usually get. Home customers should get a /56 of IPv6, that still leaves space for 256 subnets with basically unlimited hosts in them. Not too bad I think.
I never got why they had to make it that large. I doubt we'll ever want to have that many devices with their unique ip. So why not have a simpler system that makes switching easier? Even one octlet more in ipv4 would've sufficed for a very long time, two would've probably been enough forever.
Two reasons I think.
The first is, they were working on this before the Internet was widely used. Back in dialup days, pre-2000, the draft presented in 1998, working on it in 1995 and before surely.
Compared to today's scope and size, this was nascent/early style change, in something which was constantly changing.
They didn't see any contention likely at the time. Why not have all the universities, government departments, and research bodies switch? This was an entirely different landscape compared to today.
So in their eyes, why not make change? It wasn't a big deal, hell back in the early 90s, people were using token ring adapters/networking still in many offices!!
The second thing is, NAT wasn't a thing back then. The computational power was a limiter for large scale usage.
An RFC for NAT came out in 98 I think, and Linux had ipmasq, but that was brand new in the early 90s.
Basically, ipv6 was crafted before anyone had any idea we'd be where we are today.
In fact, the worry about address space exhaustion in the early 90s was due to a lack of NAT, or even the idea that it could be deployed everywhere at scale.
Where would all the compute power for NAT at scale come from?!
So basically, it was crafted with a different viewpoint.
The first is, they were working on this before the Internet was widely used. Back in dialup days, pre-2000, the draft presented in 1998, working on it in 1995 and before surely.
Compared to today's scope and size, this was nascent/early style change, in something which was constantly changing.
They didn't see any contention likely at the time. Why not have all the universities, government departments, and research bodies switch? This was an entirely different landscape compared to today.
So in their eyes, why not make change? It wasn't a big deal, hell back in the early 90s, people were using token ring adapters/networking still in many offices!!
The second thing is, NAT wasn't a thing back then. The computational power was a limiter for large scale usage.
An RFC for NAT came out in 98 I think, and Linux had ipmasq, but that was brand new in the early 90s.
Basically, ipv6 was crafted before anyone had any idea we'd be where we are today.
In fact, the worry about address space exhaustion in the early 90s was due to a lack of NAT, or even the idea that it could be deployed everywhere at scale.
Where would all the compute power for NAT at scale come from?!
So basically, it was crafted with a different viewpoint.
I wonder how much electricity NAT is consuming globally?
That would be a good BS level graduate thesis paper for someone interested.
That would be a good BS level graduate thesis paper for someone interested.
I think the sand and the grass can use NAT :)
Society will collapse before we ever have a need for more IPs than what’s in v6.
AWS has the best IPv6 support of any cloud. It came 15 years late but they finally caught up.
There's still lots of brokenness in GCP IPV6 world...
I really wish cloud providers would just emulate a bare metal network cable that I can send any kind of packets over... Then I could update to IPv7 whenever I damn well please!
I really wish cloud providers would just emulate a bare metal network cable that I can send any kind of packets over... Then I could update to IPv7 whenever I damn well please!
Emulating L2 Ethernet is more complex than the VPC they have now. VPC is also forcing apps to become more robust and scalable.
Azure is really supporting use of IPv6.
you can get IPv6 addresses from Azure for the same cheap price you can get IPv4 addresses for!
not ridiculous at all.
you can get IPv6 addresses from Azure for the same cheap price you can get IPv4 addresses for!
not ridiculous at all.
Hetzner is actually good there. They now charge you separately for ipv4 but give ipv6 for free. And when they changed it, they reduced server prices by the ipv4 price. So you could actually save money switching. It tends to be 5% or less, but seeing it a separate line item might make people think if they really need ipv4.
In sum, we only found two companies that are using 240/4 IP space privately.
If anything, this is almost a warning from ARIN that this block might be finally repurposed. They find no one using it except for two companies internally ; they're seeking to see if 240/reserved is used or not is seems.
And really, anyone using 240 is to blame if it does get repurposed, so it seems like a good idea.
If anything, this is almost a warning from ARIN that this block might be finally repurposed. They find no one using it except for two companies internally ; they're seeking to see if 240/reserved is used or not is seems.
And really, anyone using 240 is to blame if it does get repurposed, so it seems like a good idea.
To blame, maybe. But say you get a class E network. Are you fine not being able to talk to anything hosted on AWS?
Blame is not correlated with pain.
Blame is not correlated with pain.
You may have difficulty talking to other things, too. Older equipment simply won't communicate with class E addresses. It's hard coded in! It works for AWS because they control their network, end-to-end.
It may take a year or two, but I think AWS would clean up its act. I'd be worried about some megacorp using it inside some deep internal project, and for a decade after having bizarre deliverabilities issues for mail or something, randomly, without its staff understanding why.
I think a year or two may be optimistic. One can only assume that if you start using class E then you've already used up all of 10/8. So the only option is to move to IPv6.
I don't know AWS internals, but they may need to do hardware revisions they need to roll out to switch ASICs, not to mention millions of lines of code.
And the addresses will be "kinda broken" everywhere, basically forever. So AWS wouldn't even get the blame. So there's no incentive for them to have a moon landing program costing them many billions, throwing away hardware before they otherwise would.
Of course it is 2022, so I would hope that AWS's current production hardware is IPv6 ready at equal pps, FIB size, and features, but I wouldn't be surprised if not.
But the software should not be underestimated. That IPv4 address in a database, stored as 32bit integer, is not exactly trivial to extend on disk and by every single reader and writer.
Nobody will want these second class addresses, not on the client nor the server, so who are they for?
(on the public Internet, that is. They could be used as 100.64.0.0/10)
I don't know AWS internals, but they may need to do hardware revisions they need to roll out to switch ASICs, not to mention millions of lines of code.
And the addresses will be "kinda broken" everywhere, basically forever. So AWS wouldn't even get the blame. So there's no incentive for them to have a moon landing program costing them many billions, throwing away hardware before they otherwise would.
Of course it is 2022, so I would hope that AWS's current production hardware is IPv6 ready at equal pps, FIB size, and features, but I wouldn't be surprised if not.
But the software should not be underestimated. That IPv4 address in a database, stored as 32bit integer, is not exactly trivial to extend on disk and by every single reader and writer.
Nobody will want these second class addresses, not on the client nor the server, so who are they for?
(on the public Internet, that is. They could be used as 100.64.0.0/10)
255.255.255.255 is the broadcast address and all other 240/4 are "for research purposes." IPv4 doesn't need "research" anymore because it's as dead as a whale oil barrel patch kit. I say fine: use them and un-bogon them. And then also deprecate the IPv4 internet by Dec 31, 2029.
Can't migrate to IPv6 without having a real deadline.
That's how it has to be because adoption that's optional never happens: look at the US and metrication.
Can't migrate to IPv6 without having a real deadline.
That's how it has to be because adoption that's optional never happens: look at the US and metrication.
For it to be visible at BGP level I suppose they must be used publicly? But that aside, as a a bad practice, surely you can basically use any IP that you're not supposed to, as long as you don't care that it stops the real one being reachable? I.e. 'reserved for future use' can be considered 'private use if you must, for now, may change without notice'?
These aren’t being announced at the edge. They’re appearing in traceroute responses, and some are directly reachable from inside the AS, which means they’re appearing in the IGP. Announcing networks in this range to peers would be an huge no-no.
You can’t just use any IP: some are truly special (e.g. the multicast range) and 240/4 is still treated as invalid by many currently deployed IP stacks in their off-the-shelf configuration. Getting away with this only works at the kind of integration scale where you’re smelting your own copper, so to speak.
You can’t just use any IP: some are truly special (e.g. the multicast range) and 240/4 is still treated as invalid by many currently deployed IP stacks in their off-the-shelf configuration. Getting away with this only works at the kind of integration scale where you’re smelting your own copper, so to speak.
They are only visible in traceroutes. Ripe seems to operate devices to collect BGP stats that also do periodic traceroute. Some of the packets they sent out crossed a router with IPs in the 240/4 block, but those are only used internally and not advertised outside the AS (apart from the suspicion of different Amazon AS advertising their 240/4 addresses to each other).
RIPE have been running Internet observatories for decades. I remember the members of the TTM (test-traffic measurement) project in the late 90s trying to get ISPs to install GPS receivers on the DC roof for accurate one-way latency observations.
This is using RIPE Atlas.
The actual probes are tiny consumer grade routers (https://www.google.com/search?q=ripe+atlas+probe&tbm=isch) with a new firmware. RIPE provides these free of charge to volunteers (people and companies) who then run them in their network (e.g. homes and datacenters). (Of course larger form factors are available to volunteers with more in-demand locations.)
In return, volunteers get rewarded for uptime of their probes with credits that can be used to request custom measurements from the Atlas network.
There are probes _everywhere_; not just in terms of geography (https://atlas.ripe.net/results/maps/) but also in network locations that you cannot get access to via any other means; there really is no other service that comes close in terms of reach for global internet status testing.
The actual probes are tiny consumer grade routers (https://www.google.com/search?q=ripe+atlas+probe&tbm=isch) with a new firmware. RIPE provides these free of charge to volunteers (people and companies) who then run them in their network (e.g. homes and datacenters). (Of course larger form factors are available to volunteers with more in-demand locations.)
In return, volunteers get rewarded for uptime of their probes with credits that can be used to request custom measurements from the Atlas network.
There are probes _everywhere_; not just in terms of geography (https://atlas.ripe.net/results/maps/) but also in network locations that you cannot get access to via any other means; there really is no other service that comes close in terms of reach for global internet status testing.
RIPE Atlas is an amazing project. I remember getting 3 probes at a NANOG and telling my coworkers about it. They couldn't believe that it was a free project, and that I didn't have to pay anything for the probes. Great stuff from RIPE, for free! (Anchors cost dough but probes were free)
Couple points:
a. Do linux/windows just take it 240/4 address without special attention?
b. Fun time when 240/4 will be released to public in the future it's gonna be a huge headache for them.
a. Do linux/windows just take it 240/4 address without special attention?
b. Fun time when 240/4 will be released to public in the future it's gonna be a huge headache for them.
Linux has supported 240/4 addresses for years, but Windows still does not.
Yeah, most Unix systems have been more or less OK with it since the prior round of Internet-Drafts in 2008. Some more details in the implementation status section in https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas... (which I'll need to continue updating on the basis of more tests).
The situation is more complicated for routers, including high-end datacenter routers. (If you have something that's post-2008 Linux under the hood, it probably works although there might be some higher-level software enforcing special cases.) The trend has been toward more router support for 240/4, but the special case was historically enforced in many devices, and older routers sometimes stay in use for quite a while.
Windows is definitely the outlier on endpoints; when I gave some presentations about 240/4 over the past year I pointed out that, if people were watching them on a device running anything other than Windows, that device would most likely interoperate with 240/4 addresses.
The situation is more complicated for routers, including high-end datacenter routers. (If you have something that's post-2008 Linux under the hood, it probably works although there might be some higher-level software enforcing special cases.) The trend has been toward more router support for 240/4, but the special case was historically enforced in many devices, and older routers sometimes stay in use for quite a while.
Windows is definitely the outlier on endpoints; when I gave some presentations about 240/4 over the past year I pointed out that, if people were watching them on a device running anything other than Windows, that device would most likely interoperate with 240/4 addresses.
> many people wonder why there is still a market for IPv4
This is so tone deaf.
Put it this way, if Verizon, Google, and Facebook weren’t the champions for IPV6 for rolling it out, I’d be on board.
First and foremost: ipv6 is unnecessary for the end user, ipv4 provides the default assumption that a casual anonymizing NAT is in use.
And we can be real: SRV records, SNI, NAT work just fine and solved all the problems IPV6 went to solve _from the consumer perspective _.
I know this comment will be incredibly unpopular on HN, but the points need to be addressed. Your ISP is not your friend and neither are these other companies that sell your information without your explicit consent.
This is so tone deaf.
Put it this way, if Verizon, Google, and Facebook weren’t the champions for IPV6 for rolling it out, I’d be on board.
First and foremost: ipv6 is unnecessary for the end user, ipv4 provides the default assumption that a casual anonymizing NAT is in use.
And we can be real: SRV records, SNI, NAT work just fine and solved all the problems IPV6 went to solve _from the consumer perspective _.
I know this comment will be incredibly unpopular on HN, but the points need to be addressed. Your ISP is not your friend and neither are these other companies that sell your information without your explicit consent.
> NAT work[s] just fine
It's sort of tolerable if it happens on your home router which is under your control, but its absolutely a pain in the backside if it's done on the ISP level (CGNAT) and you want to self-host anything from your home network, like multiplayer mode in some games, or whatever…
It's sort of tolerable if it happens on your home router which is under your control, but its absolutely a pain in the backside if it's done on the ISP level (CGNAT) and you want to self-host anything from your home network, like multiplayer mode in some games, or whatever…
Just curious, how does ipv6 solve multiplayer mode? Even with ipv6, you absolutely need to drop inbound traffic from the internet to devices on your LAN... am I not understanding something with ipv6?
No NAT traversal nor double NAT, you can just open the port on your firewall and it'd work.
This is a very simplistic view. IPv6 doesn't meaningfully improve or hinder your anonymity compared to IPv4 behind NAT. Facebook, Google will in the common case obtain way better fingerprint by using many techniques together. Your ISP has a contract with your address on it and is usually required by law to keep records. It will know what happens independent of IPv4 or IPv6 - you will still get the blame and privacy extensions have a similar effect here like NAT.
If everybody was just a consumer all the time, we would have a very different (worse) society overall. There is a reason a subset of technical people do want IPv6 even if it means way more work for them.
If everybody was just a consumer all the time, we would have a very different (worse) society overall. There is a reason a subset of technical people do want IPv6 even if it means way more work for them.
NAT doesn't work "just fine".
ISPs have been deployed for years without IPv4 or bad IPv4 (see this thread). And even not counting those ISPs there are countless more than would completely fall over if the major players stop announcing IPv6.
They just don't have the CGNAT capacity to run the internet without IPv6.
Strictly from the consumer perspective this means buggier, slower, and more expensive internet. Consumers don't care about bits, but their dollars he to buy the CGNAT and other crap.
And it'll only get more and more expensive (for the customers).
ISPs have been deployed for years without IPv4 or bad IPv4 (see this thread). And even not counting those ISPs there are countless more than would completely fall over if the major players stop announcing IPv6.
They just don't have the CGNAT capacity to run the internet without IPv6.
Strictly from the consumer perspective this means buggier, slower, and more expensive internet. Consumers don't care about bits, but their dollars he to buy the CGNAT and other crap.
And it'll only get more and more expensive (for the customers).
can someone explain what this means :p sorry
Big companies are using groups of IP addresses internally on their private networks which technically aren’t supposed to be used anywhere. This is mostly fine and no one cares too much.
> This is mostly fine and no one cares too much.
Until it breaks something, as was the case with 1.1.1.1
Until it breaks something, as was the case with 1.1.1.1
You can't dent the universe without breaking some things. It's inevitable. Adapt. Overcome. It'll be okay.
Could someone explain how this "breaking" works?
If 240/0 ends up being assigned as private address space, it won’t matter since that’s how these companies are already using it. If, however, it’s assigned as public address space, then these addresses would potentially (depending on their routing) be unreachable from the networks of the companies already using them as private addresses.
What happened with 1.1.1.1?
I’m guessing 1.1.1.1 being used as a private IP in cases like this: https://community.cisco.com/t5/wireless-mobility-knowledge-b...
Yeah, so about that:
https://github.com/seligman/aws-ip-ranges/commit/2e0d9d87d4f...
They did briefly list 252.0.0.0/10 in their published list of IP ranges. The people I spoke with about this at the time either claimed it was a mistake, or the state of the world that I should get used to (it broke some surprisingly fragile scripts on my side for silly reasons).
Given they removed it from their list of IPs 27 hours later, I'm guessing I wasn't the only person freaking out. But yeah, they use it internally, and it leaks from time to time in surprising ways.