Previous owner was GE.
Anecdotal reports across the Internet that AWS EIPs are now being assigned in that range.
https://whois.arin.net/rest/net/NET-3-0-0-0-1.html
https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
http://maps.measurement-factory.com/
It's a great purchase for them, and a shot at Azure and GCP - Amazon can now legitimately tell larger clients "we will have enough IPv4 space to be your partner for all your static-IP-dependent applications, no matter how much you need to scale."
Hugged to death.
https://www.caida.org/research/id-consumption/whois-map/imag...
Each pixel in the image is a /24 network.
Debis = Daimler-Benz InterServices, sold to T-Mobile (specifically T-Services) in the early 2000s
CAP Debis was a partnership with CAP Gemini.
Today it's mostly enterprise telecom/IT, though that maybe oversimplifies things. It's a big beast in Europe, Germany specifically.
https://blog.wireshark.org/2010/04/t-mobile-clever-or-insane...
[1]: https://www.internetsociety.org/blog/2017/05/mit-goes-on-ipv...
Sure its a big block, but its still "only" ~16 million addresses
that sort of thing would be cool to learn
AFRINIC: African Network Information Center ARIN: American Registry for Internet Numbers APNIC: Asia-Pacific Network Information Centre LACNIC: Latin America and Caribbean Network Information Centre RIPE: Réseaux IP Européens
it's mostly used for internet television or other multimedia stuff.
(some stuff is/was unallocated, since some early users tought it's a good idea to actually use some unallocated stuff to do bgp..., testing or routing per se (especially cisco routers) or even login pages, exist nodes, i.e. 1.0.0.0 was a problematic ip, but since cloudflare grabbed the 1.1.1.1 I think people will stop doing stupid things)
On a Local network, multicast is very easy to do. Unless it's very, very old your computer almost certainly uses multicast on local networks already, for a variety of purposes. A dumb old network just sent all packets to all computers on the local network, so both broadcast and multicast were equally easy to do, your network card has a filter built into it, that autonomously weeds out messages your computer cares about, and ignores the others - so the Operating system is like "Hey, network card, my unicast address is 10.20.30.40, and I am also listening to multicast address 224.0.0.251" and it will just throw away any packets that aren't for those addresses. A smart modern network (e.g. the mid-range gigabit switch serving your desk at work) keeps track of which addresses are where and sends copies of messages only to where they seem useful, leaving more network bandwidth for everybody else.
The Internet can in theory do Multicast too. I've used this to, for example, watch television with a dozen other people without any copy of the TV picture data being sent over the shared data link to us more than once. That's what those addresses are for, you "Join" one of the multicast addresses and begin receiving, say, the Olympics live.
However making all this work is hard, and in most places, most of the time, nobody puts in all that hard work, so probably you'll find that although local network multicast works for you (as I said it's used in modern systems) you cannot use the Internet's multicast features. Which is a shame, but we can't have nice things.
It isn't used because of the economics behind the ISP business.
With multicast a single sender can have arbitrary many receivers but sends its data only once. The network infrastructure 'clones' than that data on its way to the receivers as necessary. But that's not in line with the economic interests of an ISP.
With unicast the sender has to use increasingly more bandwidth when he wants to reach more receivers, and the ISP gets payed for that additional bandwidth. The more bandwidth the sender uses the more money makes the ISP. With multicast on the other hand the sender needs to send everything only once no mater how many receivers are listening.
Imagine you could send an audio or video stream to potentially everyone with internet access in the whole world but would need to pay only for the bandwidth of exactly one stream. That would be very nice for you, or Spotify, or Netflix, but not such a good deal as the current one for your ISP.
That's why ISPs don't sell multicast connectivity. Technically it would be easy. The current network-infrastructure would be able to handle multicast (almost) without any additional effort on the carrier side. After all the technology is build in in almost every switch or router for years now. Live streaming of AV media would be possible for everyone with internet access. One would not need the bandwidth of say YouTube to reach as many receivers as they do. But that will never happen because ISPs just aren't interested in providing multicast connectivity!
This mostly happens with Akamai [1] and Netflix [2] CDN appliances on edge networks though (content caching boxes used to offload transit or peering fabric traffic). I'd argue Multicast didn't take off because of "tragedy of the commons" issues; ISPs don't want to support additional complex network routing technologies (at additional, substantial cost) when existing one to many unicast solutions (mentioned above) are sufficient.
[1] https://www.akamai.com/us/en/multimedia/documents/akamai/aka...
[2] https://media.netflix.com/en/company-blog/how-netflix-works-...
Netflix, Spotify, and other services with on-demand content couldn't use it unless they made the service worse by forcing viewers to wait for a multicast.
Pausing and resuming elsewhere would mean changing to a different multicast stream or starting a new one if there weren't any before.
Also:
We have the technology! But capitalism.
It's pretty crazy though that that huge range goes to Amazon in full. Wouldn't it have been better for the health of the internet as a whole to get them back to IANA for redistribution?
Meanwhile, if Amazon is going to use all these in the medium-term future, that seems OK to me.
(3.3.3.3 and 3.2.1.0 would be more memorable.)
DHCP giving out a client address of 192.168.1.0 in the middle of a lagre block sure, but a router?
Many home routers issue IPs using the follow netblock:
Network: 192.168.1.0 Netmask: 255.255.255.0 (/24) Broadcast: 192.168.1.255
Gateway: 192.168.1.1 (the first valid IP in that block) or less often .254 (the last valid IP in that block)
So for the past thirty years, nearly _every_ network block issued by _any_ network admin used /24, to the point that some things simply refuse .0 and .255 as valid IP addresses.
The suggestion upstream is to set up the IP 3.2.1.0, within _any_ network block that can contain it legally. If you adhere to strict netmasking, that'd be (this is from memory, correct me if I'm wrong):
Network: 3.2.0.0 Netmask: 255.255.254.0 (/23) Broadcast: 3.2.1.255
Which would provide a contiguous block of valid IPs from 3.2.0.1 through 3.2.1.254, _including_ the two perfectly valid IPs 3.2.0.255 and 3.2.1.0.
Those valid IPs end in .255 and .0, which is completely legal since they're in the middle of a /23, and the default gateway wouldn't be anywhere near them.
A lot of human-operated networks will blacklist issuing .0, .1, .254, .255 on the theory that it's simpler to just prohibit them and lose 4 IPs per /24 within a block, than deal with what's truly possible for a /23 or wider block.
EDIT:
Public BGP requires /24 or wider, and /24 cannot contain .0 or .255 as a valid IP, so the next widest is /23, which can contain even-numbered .x.255 and .x+1.0. If you're doing this on an internal network that permits narrower subnets, the narrowest available would be a /30, based (irregularly) on either .1.254 or .1.255:
Network: 3.2.0.254 (or .255) Netmask: 255.255.255.252 (/30) Broadcast: 3.2.1.1 (or .2)
With 3.2.1.0 as the live IP and either 3.2.0.255 or 3.2.1.1 as the in-network gateway for that device.
That requirement is about how you advertise your routes not how you subnetted the internal network. .0 and .255 of your advertised /24 can work fine as /32s on the server. Using the internet FW to NAT the network and broadcast addresses is another common trick to get more addresses, particularly when you only get an e.g. /29 from a carrier who is just routing that /29 to your specified next hop and 2 more addresses is a big bump.
In classful addressing it is a network 3.0.0.0 with a netmask 255.0.0.0 (/8). In a classless, it is whatever has been advertised to me.
> Public BGP requires /24 or wider, and /24 cannot contain .0 or .255 as a valid IP, so the next widest is /23, which can contain even-numbered .x.255 and .x+1.0. If you're doing this on an internal network that permits narrower subnets, the narrowest available would be a /30, based (irregularly) on either .1.254 or .1.255:
It does not. You can advertise whatever the hell you want. What matters is what the other side would accept. It used to be that no one would accept anything less specific than /24 in a class C address space, /16 in a class B address space and /8 in a class A address space because the internet ran on AGS and maybe AGS+ which just did not have enough memory to do real classless. That stopped around the time GlobalCrossing showed up (or maybe around the time Mr V did terrible things while running AS7007). But anyway, ten years ago /27s are definitely accepted routes by those that comprised over 80% of the gloabal internet by the single origin prefixes.
Are there any publicly advertised, unsummarised /31s or /32s in the global BGP tables?
Only /31s could include .0 and .255 and those would end up on router point to point links.
> Are there any publicly advertised, unsummarised /31s or /32s in the global BGP tables?
I filter them out as martians, so I cannot answer this.
Even in 2003, the network I was involved in was handing out .0s out of larger CIDR blocks in DHCP leases with no issues.
I've spent the past two weeks just trying to fix some horribly wrong/invalid data that is absolutely positively guaranteed to always be correct due to certain standards and lots of money and one of the biggest best tech companies in the world stands behind it.
Guess what it's still broken they just refuse to admit it.
"be conservative in what you do, be liberal in what you accept from others"
And there's no takebacks -- once you start permitting something, you can't take it away later, or you'll break things. You're creating more legacy requirements that may cause you problems when you try to evolve in the future.
As a web developer, I can only dream of how clean web standards might be today if the browsers of yore were a bit more conservative.
They're a CDN and send out a lot of bits, so every last bit of inbound traffic helps. Or am I totally off base on this?
I would have thought that they would go with the simplest measure possible, bytes in vs bytes out.
Most network providers have peering agreements to handle reciprocal traffic flows. In other words, if you're Comcast, you send a shit-ton of traffic to, say, Verizon. But Verizon also sends a shit-ton of traffic to you, as well. Generally, companies will have peering agreements that express the price for which they will route traffic for other network providers, and generally if there's a lot of reciprocal traffic, the peering will be "settlement free" - in other words, neither party charges the other to route traffic. So, in the example above, you as Comcast would agree to route Verizon's traffic across your network for free as long as Verizon did the same.
Cloudflare is a CDN, which means they push a LOT of traffic out across a lot of networks, and it's likely they're not getting as much inbound traffic as they're pushing out. That makes it harder for them to negotiate settlement-free peering, since they're not providing as much reciprocal value to their partners. By owning 1.1.1.1, they can now claim any trafic sent to that IP as "inbound" to Cloudflare's networks for the sake of peering agreements. Since 1.1.1.1 gets a bunch of traffic from either misconfigured equipment or people doing silly tests, routing that traffic helps improve Cloudflare's ability to negotiate better peering agreements.
Which, honestly, is pretty clever, since most of that traffic is garbage.
Nobody expects a residential ISP or a CDN to have balanced flows at part of a settlement-free peering agreement.
I vaguely recall a site that that shows approximate throughput for given properties but I can't remember the terms to google for to (re)find it. But 1.1.1.1 might not be listed - or the numbers might only represent valid traffic and be wildly inaccurate.
Traffic breakdowns would thus be very interesting to see (for whatever is shareable, at least - heh, you'd probably have enough fireside stories to drown multiple HNs with :) ). In the case of 1.1.1.1 I'm wondering about what percentage of traffic is coming from valid DNS clients (and I also wonder where the requests are coming from - although that's just trivia to me), versus eg nonsense from horribly misconfigured lightbulbs.
3.14.15.9
But instead I would want a webserver on there that just serves up digits of Pi.
At this point it seems like a desperate play by a company with deeply entrenched IPv4-only infrastructure (hi EC2) to eke out more time without major upgrades. Meanwhile IPv4 addresses remain scarce for small ISPs, and the (healthy, natural) push to IPv6 infrastructure continues apace everywhere else.
https://docs.aws.amazon.com/vpc/latest/userguide/get-started...
(I'm aware a lot of things happened in 2010, but (as someone interested in the industry but somewhat removed from it) I'm not aware of anything that specifically happened in 2010 that changed the landscape in a big way.)
(or just want to interoperate, even)
What kind of tricks are you afraid of these DNS services could get up to?
While it doesn't support live comparison of DNS results, it can log out entries per DNS resolver and you can post-process those logs to validate their responses against each other, considering your queries will over time hit different resolvers. Not perfect since there are legitimate reasons to return different responses over time, but it's something.
[1] https://github.com/jedisct1/dnscrypt-proxy [2] https://github.com/jedisct1/dnscrypt-proxy/wiki/Load-Balanci...
That IPV6 adoption is slow is precisy because buying ranges of IPV4 addresses is still cheap enough that people are doing it.
ISPs can basically get all the IPv6 resources they need, but IPv4 addresses are becoming scarce and costly. Amazon just spent a lot of money to get more IPv4 addresses: that's cost, not profit.
If Amazon owned all the addresses and they were making great profits as a monopoly seller, this would indeed be an incentive not to move to IPv6. Instead, it's really just driving up people's costs.
Adoption is slow because the extra costs of IPv4 addresses are still smaller than the costs of really getting every piece of infrastructure and software working correctly with IPv6. We're not that far away, but there's a bit of a chicken-and-egg problem until we're close enough that people can start to turn off IPv4 and effectively force stragglers to adopt.
Retail in general wants to know a lot about you.
PS: I don’t know about Amazon Echo, but it’s definitely on the creepy side of data privacy.
-ss
Network address is only really used for directly attached networks, non directly attached networks will route to any address in the block correctly.
Same for broadcast address, they're also relative to whatever block you're talking about at the time, so whilst 3.255.255.255 is the broadcast for 3.0.0.0/8 subnet it's just another "usable" address in the 3.0.0.0/5 subnet and when you send a packet then you, and probably your router, don't know what subnets in use on the other side :) (unless it's directly attached)
3.255.255.255 would be the default broadcast address, but not only can you use a different address (in fact, any address you want for broadcast, you just need to configure it), but this is also not a real /8... it's 3.0.0.0/15 according to ARIN.
https://whois.arin.net/rest/net/NET-3-0-0-0-2/pft?s=3.0.0.0
3.255.255.255 is default broadcast for 3.128.0.0/9.
Broadcast addresses have no meaning outside of a broadcast domain / subnet. Nobody would use a full /9 as a subnet. It would be split into much smaller blocks...
Do they then cover Seattle in stickers and chalking with 3.3.3.3?
They also have 18.128.0.0/9, bought from MIT.
https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges....
Depending on how much it actually cost I feel like it could be a number of things from simple branding to nefarious traffic shaping. If you're an AWS shop maybe they want you to be able to set simple bypass/static route for 3.0.0.0/8.
At $14 per IP: 2^24 * $14 = $235mm
Price per IP estimated from:
https://www.ipv4auctions.com/
GCP only supports it on the edge for their load balancers for instance.
[1] Cali., Denver, Zurich, Hong Kong
On the hosting service I use, you can rent an IPv6 only host and you pay less. Why would you pay for an IPv4 address if you don't need it ?
Last I recall (years ago) my buddy was running some type of VPN through Comcast just to be able to use IPv6 properly. That's when I decided it was still too new for me.
Clearly I don't know anything on the subject, and I'm not claiming to. These are one of the areas where I don't know, don't desire to know, and want it to "just work". I am however interested in making my applications compliant asap, but until I can reliably use it, I've not even attempted.
So with that big pile of ignorance, are we "there yet"? Ie, could I build applications and run them on a IPv6 compatible host, with hit it with my home ISP with a reasonable expectation that everything will work? (assuming my code works, of course).
I feel like I need a "caniuseIPv6.com" site, similar to https://caniuse.com. From the outside, IPv6 implementation and support seems bizarrely cryptic.
On the modem side, nothing needed to be done for IPv6. Any firmware updates or configuration needed is done by Comcast.
On the router side, there is a dedicated IPv6 configuration page. Settings are:
• Connection Type: Native
• All other available settings: Set to either 'Enable' or 'Stateless'.
That was it. My Mac has IPv6 configuration set to configure 'Automatically', and I get an IP. If I go to plain Google and ask it "what's my ip" I get a IPv6 IP back.
On my iPhone, on wifi, if I do the same "what's my ip" Google search, I get an IPv6 back. My carrier is Ting GSM; if I turn off wifi and do the same Google search, I get a different IPv6 IP back.
At work, IPv6 is rolling out _very_ slowly, but I was able to get a fixed IPv6 address. That has been programmed into the configuration for my laptop's USB-Ethernet adapter, so I have IPv6 at my desk at work. Although most work services are not IPv6-enabled, DNS is.
And at home, IPv6 is enabled and is in active use, both on desktop and on mobile.
As for testing, I suggest https://test-ipv6.com and https://ipv6test.google.com
(Yes, all IPv4 addresses can be represented as IPv6 addresses in a reserved zero prefix network, some network APIs just offer IPv6 and then treat IPv4 addresses this way for convenience, but we obviously don't route packets this way since those would be IPv6 packets, yet they're for an IPv4 destination which can't read them)
In some very large deployments they do v6-only. Everything internally is IPv6, when you connect to that IPv4 only site you'd actually connect to a company-provided gateway that speaks IPv6 on your side but IPv4 to the outside world.
If you're big enough this makes loads of sense - now you have this vast address space for everything, all your systems are simply configured for IPv6 only (not twice the configuration) and it pretty much just works. You buy some specialist appliances at the edge for that translation, but your users only have IPv6 stuff.
I'd welcome someone showing me how that was basically impossible, but I don't see why the entire IPv4 space isn't in a special prefix / address space of ipv6 since they allegedly have so many atoms of mappings.
Neither of these changes are required if there is a dual stack proxy or CDN that sits infront of your application, as they will most likely talk to your application over IPv4.
The other gotcha is if you try to interrogate clientIP for analytics, authorization, geo-ip etc, which may need a little more care.
(As a comcast customer that "one day" for me was several years ago)
Lots of things fail if you're IPv6 only, but it was a useful experiment and I'll try it again in a year or two.
Right now most of my hosts are dual-stack, and I have a /64 setup for my home network.
Ok, the xkcd is about nanobots with a volume of "a few cubic microns"[1], whereas atoms are much smaller.
[1] https://www.explainxkcd.com/wiki/index.php/865:_Nanobots
At home you've been using IPv6 passively for 18 months, it works and you never noticed.
Hence the big up spike on weekends and major holidays.
IPv6 is the future of IP connectivity, that is not going to change.
If you want an IPv6 address over your existing IPv4 connectivity, you can get one in a number of ways - that’s an overlay network that is already supported by a massive amount of hardware and free software.
And it's the general-purpose computing devices that are lagging in IPv6 support, not the networking-centric hardware implementations. It's been quite a while since business-quality networking devices shipped without IPv6 support.
For those home / small-business routers which still lack support, that is probably going to be a software implementation either way, and at the very least the software nature of any IPv6 implementation added through a "firmware" update (really just an OS update) won't be a performance bottleneck for those devices.
In some of those cases a firmware update has even been released by the manufacturer, just not applied. In many more, IPv6 is supported by the networking device and the software/firmware but simply disabled, or not supported by one or both of the ISP and the end-user device.
And how many will they need to install? Will everyone install a generic one that all software just works with? Kinda sounds like IPv6, just with the added network in network overheads, and a competitor (IPv6) that's years ahead in terms of real world deployment.
And then there's the suggestion ISPs could run these popular overlay network nodes, that customers don't even need IP. I'll pass on slicing up the internet into walled gardens that's ISPs get to choose which overlay networks you can access!
And ISPs shouldn't be able to do any harm with those transport nodes, they shouldn't be able to even see what kind of stuff those nodes proxy.
Ignoring that massive issue, which daemons get installed? Who installs them? Who updates them? End users won't. So it's up to the Software+OS vendor and ISP - Just like IPv6.
Don't get me wrong, IPv6 has been, so far, a pretty epic failure in terms of adoption. But your plan seems to put it all in the hands of the exact same people, but at the same time, gives them a massive incentive to partition the internet into a whole bunch of tiny walled gardens.
Why should this turn out any better than IPv6?
https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers
https://en.wikipedia.org/wiki/6to4
The time to bikeshed this stuff is long, long passed, take the time, understand the options, stop writing off ipv6 as impractical, or never going to happen, nobody is writing a (different) overlay network.
No clear prescriptions for legacy v4 <-> v6 translations, religious hate of NAT, unfortunate separator character (the colon) that is used for domain:port separation. Separate stack prescriptions.
I honestly think it would have been easier to do a rolling upgrade of the internet to support bigger numbers in the four coordinates of IP addresses and increase the number of ports.
I'm obviously not a deep networking expert, but as I've been exposed to IPv6 test conversions it's been painful.
It should never have been adopted in the first place but now it's the only practical option for moving forward.
Customer <> us Office <> us Us @aws <> us @azure
With having so many customers there are probably enough with use cases which requires that ipv4 and having them is probably a necessity.
Perhaps it didn't feel like it as much at the time, since only huge corporations had the need for so many computers.
Companies like Merck and Ford, Universities like MIT, don't appear to have paid a dime for them.
So you got a /8 by asking for one; they handed them out for free.
Same goes for DNS. You used to request the name and it was yours. No yearly fees.
The IP blocks were never reclaimed because it was pointless. Even now clawing back the big /8 assignments only kicks the can down the road for a year, maybe two.
My company has a /32 ipv6 space. That's 79228162514264337593543950336 /128s. And we got it by... just asking for it.
I know everyone's shouting about "there are enough IPs for every atom on earth!" but just like "no one understood that over half of all humans would be on the internet", maybe we'll need more IPs in the future becuase of some unforeseen development... it seems silly to be handing out blocks like this just for giggles.
There was an article about this recently on the German news site Heise: https://heise.de/-4196981
Translation: https://translate.google.com/translate?sl=auto&tl=en&js=y&pr...
Hence, there were no fees. Stop engaging in pointless (and even incorrect!) sophistry.
The National Science Foundation paid Network Solutions a payment, per registered domain, in exchange for the service of registering it.
The recent purchase of OpenShift may be a good answer to 'I wonder what they are intending to do with a /8 in a year'.
Why does Amazon want it? - Amazon has a lot of customers who want EC2/ELB instances with their own IP addresses. IPv4 addresses are a scarce resource.
Why did GE have it? When the IPv4 address space was formed, various big US companies managed to get the initial IP address allocations. You can see more on these allocations here: https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...
Why so many upvotes? It's relatively rare to see what is 1/255th of the IPv4 address space sold.
Also, That Wikipedia article was particularly helpful. I knew the /32 was specific to my IP that I use but didn't realize the sheer scale of those blocks.
There is another comment here that said Amazon paid ~18/IP. They won't pay this next year.
Amazon probably wants it to sell to their customers who need ipv4 instead of v6
In binary, a /8 netmask would look like this: 11111111.00000000.00000000.00000000 and a /16 would look like this: 11111111.11111111.00000000.00000000
So 3.0.0.0/8 means only the first eight bits are fixed. Which gives Amazon 2^24 IP-Addresses to use (32-8 bit). That is huge because it's 1/256 of all available IPv4 addresses. It is small because it's only 16777216 addresses.
The issue is that when you have 95% of your address space allocated and unused you can't reap individual sections, and if you could then you'd bloat the BGP tables to epic proportions.
IANA/RIPE need to be more reserved when they have abundance.
Actually, that goes for technology in general; just because most of your users have 8G of ram doesn't mean you should think that using 5G is acceptable. (looking at you skype/slack/chrome)
And once enough companies buy huge ranges of IPv6, we would come to the same scarcity as in IPv4, no?
PS: I understand that largest CIDR block that can be allocated in IPv6 is /20, not /8. But they could buy 4096 blocks of size /20 to get the whole of /8.
See https://www.iana.org/assignments/ipv6-address-space/ipv6-add...
Evidence of need for an IPv4 /8 is plausible for any large organisation, but how would you show you need an IPv6 /8? "Oh, our colonies in Orion's Belt are all expanding very quickly now so we need more space" ?
Now your next question might be, hang on, if you can't buy IP addresses, how does Amazon have 3.0.0.0/8 ? Well, lots of companies can show evidence of need in IPv4 but space is exhausted - so what happens is that if somebody _else_ gives up their address space to someone who have evidence of need that's fine. And a financial inducement to give up your space to somebody else is also fine.
So in a sense you _can_ buy IPv4 addresses, just you aren't allowed to buy them if you aren't going to need them. Hoarding, speculative trading, etcetera are (in principle) not a thing.
Looking now:
134.132/16: still LGC/HAL
34/10: HAL
34.64/10: Google
34.128/10: HAL
34.192/10: Amazon
So I guess they decided to make some hefty profit...
Would love for each AWS account to have it's own IPv6 range out of the box. I feel like this solve the pains the AWS Lambda fans (like myself) have when they need to access a whitelist only service.
Disclaimer: Board strokes, I don't really know what I am talking about
3.0.0.0/15 ap-southeast-1 EC2 (Singapore) 3.8.0.0/14 eu-west-2 EC2 3.16.0.0/14 us-east-2 EC2 3.40.0.0/14 eu-west-1 EC2 3.80.0.0/12 us-east-1 EC2 3.104.0.0/14 ap-southeast-2 EC2 3.112.0.0/14 ap-northeast-1 EC2 3.120.0.0/14 eu-central-1 EC2
I can't imagine why sales and values of IP blocks would be publicly tracked (beyond just IP blocks trading hands), but is anyone aware of the sale price?
so , some smart finance people at GE may have calculated that now is a good time to put them on the market vs wait.
https://www.npr.org/sections/money/2018/10/03/654141402/what...
10 and 127.
https://www.techloaf.io/2018/11/08/amazon-hq2-now-covers-mor...
(This is a tech humor blog/email I follow - they have been vicious with Amazon this week)
And that's ignoring population growth, multiple devices per person, infrastructure addresses and overhead.
Edit: Changed likely to hopefully... as let's be honest, we'll probably still be using IPv4 in a few decades.
I'm not arguing there is (or isn't) a shortage, I'm pushing back on a point premised on the existence of a shortage. Go reply to that other guy.
Your point seems to be that a shortage is not possible because carrier grade NAT. I'd argue that the deployment of carrier grade NAT is proof that one is actively in existence.
IPv4 Addresses < 4.3 billion.
It was just a matter of time before IPv4 was insufficient, no matter how you allocate it.
Edit: wow I have no idea how that got so garbled.