Wow. This is a significant slice of the IPv4 address space, and one of the few remaining uninterrupted /8s owned by the private sector. This is a 10-year old visualization, but it's still a good one to visualize the scale of this purchase.
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."
It's really incredible how so many non-tech companies have /8s still. What is Prudential doing with all of that address space? Eli Lily?!? Who the hell is Cap Debis?
I wonder if T-mobile is aware of that purchase. Sometimes these little known assets get lost by the big predator because they were interested in something very specific of the prey company.
I'm sure TMobile is intimately familiar with their networking assets. They pioneered squatting on MoD space for internal routing to avoid dual homed conflicts. (25.0.0.0/8)
Unicast is sending messages to a single peer. Broadcast is sending messages to everybody. Multicast is in between, sending to some arbitrary set of recipients.
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.
The technical explanation of multicast is quite good. But the reason it isn't available on the internet has nothing to do with the technical hurdles.
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!
> 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.
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.
There's also the argument that few people want it, because multicast is only useful for synchronized streams.
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.
not even. more like "we've got a model that making us lots of money, lets not change just because some people keep whining about 'efficiency' and 'democratization'"
Before there was YouTube, there was MBone, a way to syndicate multicast content across the web. With multicast, in theory millions of subscribers can watch a video streamed from a single laptop (as long as they all watch in sync).
ARIN and RIPE are two of the five regional internet registries:
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
multicast is like a broadcast except that it is authenticated, i.e each device that is authenticated against a certain multicast will get the content.
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)
It's nothing to do with authentication, it's simply indicating you want the data. If authentication or encryption is used it's nothing to do with multicast.
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."