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."
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.
Sure its a big block, but its still "only" ~16 million addresses
Hugged to death.
that sort of thing would be cool to learn
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 126.96.36.199" 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  and Netflix  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.
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.
We have the technology! But capitalism.
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. 188.8.131.52 was a problematic ip, but since cloudflare grabbed the 184.108.40.206 I think people will stop doing stupid things)
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.
(220.127.116.11 and 18.104.22.168 would be more memorable.)
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?
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.
Many home routers issue IPs using the follow netblock:
Netmask: 255.255.255.0 (/24)
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 22.214.171.124, 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):
Netmask: 255.255.254.0 (/23)
Which would provide a contiguous block of valid IPs from 126.96.36.199 through 188.8.131.52, _including_ the two perfectly valid IPs 184.108.40.206 and 220.127.116.11.
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.
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: 18.104.22.168 (or .255)
Netmask: 255.255.255.252 (/30)
Broadcast: 22.214.171.124 (or .2)
With 126.96.36.199 as the live IP and either 188.8.131.52 or 184.108.40.206 as the in-network gateway for that device.
In classful addressing it is a network 220.127.116.11 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.
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.
DHCP giving out a client address of 192.168.1.0 in the middle of a lagre block sure, but a router?
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.
(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)
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.
What kind of tricks are you afraid of these DNS services could get up to?
Do they then cover Seattle in stickers and chalking with 18.104.22.168?
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.
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 22.214.171.124 is the broadcast for 126.96.36.199/8 subnet it's just another "usable" address in the 188.8.131.52/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)
184.108.40.206 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 220.127.116.11/15 according to ARIN.
18.104.22.168 is default broadcast for 22.214.171.124/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...
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.
That IPV6 adoption is slow is precisy because buying ranges of IPV4 addresses is still cheap enough that people are doing it.
They also have 126.96.36.199/9, bought from MIT.
At $14 per IP: 2^24 * $14 = $235mm
Price per IP estimated from:
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 188.8.131.52/8.
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.
Ok, the xkcd is about nanobots with a volume of "a few cubic microns", whereas atoms are much smaller.
GCP only supports it on the edge for their load balancers for instance.
 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.
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.
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.
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.
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
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.
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.
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:
and a /16 would look like this:
So 184.108.40.206/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.
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 220.127.116.11/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.
134.132/16: still LGC/HAL
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
18.104.22.168/15 ap-southeast-1 EC2 (Singapore)
22.214.171.124/14 eu-west-2 EC2
126.96.36.199/14 us-east-2 EC2
188.8.131.52/14 eu-west-1 EC2
184.108.40.206/12 us-east-1 EC2
220.127.116.11/14 ap-southeast-2 EC2
18.104.22.168/14 ap-northeast-1 EC2
22.214.171.124/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.
10 and 127.
(This is a tech humor blog/email I follow - they have been vicious with Amazon this week)
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.
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.