Hacker News new | past | comments | ask | show | jobs | submit login
Tell HN: Amazon now owns 3.0.0.0/8
565 points by STRML on Nov 8, 2018 | hide | past | favorite | 313 comments
Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.

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




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.

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."


Much larger and more readable version of this map:

https://www.caida.org/research/id-consumption/whois-map/imag...

Each pixel in the image is a /24 network.


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?


> Who the hell is Cap Debis?

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.


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)

https://blog.wireshark.org/2010/04/t-mobile-clever-or-insane...


I guess that one makes sense. I was having little luck Googling that name.


For the same reason some banks open so many branches. "Real State".


Waiting for the peak.


Gonna be a long wait.


Would love to see a more up-to-date version of this. I know MIT sold [1] a bunch of its address space not too long ago.

[1]: https://www.internetsociety.org/blog/2017/05/mit-goes-on-ipv...


Is there an up to date version of this? I wouldn't mind getting a poster of this on my wall.


seriously, me too. If no one can find one (I just tried to no avail), I'll make one myself and post it on here


Ha, I'd print it and put it on the wall too.


How come there are still unallocated spaces with the lack of free IPV4 addresses?


It's from October 2007.


" no matter how much you need to scale."

Sure its a big block, but its still "only" ~16 million addresses


They also previously bought half(?) of MIT's /8.


https://web.archive.org/web/20180427061808/http://maps.measu...

Hugged to death.


anyone have any good explanations of the image linked? like what are ARIN, RIPE, why is some unallocated, what is multicast?

that sort of thing would be cool to learn


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.

[1] https://www.akamai.com/us/en/multimedia/documents/akamai/aka...

[2] https://media.netflix.com/en/company-blog/how-netflix-works-...


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.


I bet they'd still have significant savings if they made everyone wait in 5-second lapses.

Pausing and resuming elsewhere would mean changing to a different multicast stream or starting a new one if there weren't any before.


Internode and iiNet (at least) in Australia did multicast IPTV for a while over ADSL2.

https://forums.whirlpool.net.au/archive/2521333


you make a good argument against usage based billing


Because capitalism.

Also:

We have the technology! But capitalism.


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).

https://en.m.wikipedia.org/wiki/Mbone


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


https://en.wikipedia.org/wiki/Regional_Internet_registry


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.


Similarly aged - https://xkcd.com/195/


I thought google had 8/8


Coming soon: Amazon launches free DNS service on 3.3.3.3 and 3.4.3.4?

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?


Best for the internet is encouraging IPv6. There aren't extre fees for that, so people with less money are equal.

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.)


While 3.2.1.0 is a valid IP address, some users might experience problems with IP address ending in 0. It would not be a good idea to use 3.2.1.0 if you want best compatibility with all available hardware/software on the market.


Cloudflare's work with 1.1.1.1 has demonstrated not only that it's _possible_ to use a previously-unusable IP address, but that it's _valuable_ to do so because it compels reporting of – and repair of – broken hardware and software on the market.


The cynic in me thinks that inbound traffic on 1.1.1.1 is "valuable" mostly to help balance Cloudflare's inbound vs outbound data flows. This balance is important in deciding whether their peering is settlement free.

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?


Yes, you are off base. We don't care at all about the traffic ratio with 1.1.1.1.


I would be very curious to find out what the actual bandwidth looks like.

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.


I'm 95 percent sure that every dns response is bigger than the request, so it might not help much. Although if they're getting a lot of garbage in it might be helpful.


It depends on what methodology is used to classify traffic as inbound/outbound. The large DNS response in your example counts as outbound packets, but it's part of an inbound TCP connection. I don't know how peering agreements work.


Interesting.

I would have thought that they would go with the simplest measure possible, bytes in vs bytes out.


Pardon the ignorance, but I'm curious: why is it important for them (or anybody) to receive inbound traffic, given they offer 1.1.1.1 for free? And also what does it mean "This balance is important in deciding whether their peering is settlement free."?


I'm not a network engineer, so take this with as much credibility as you'd give an explanation after a few beers:

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.


Balanced inbound/outbound traffic only matters for transit networks. That is, networks which are neither the source nor destination of the traffic they carry.

Nobody expects a residential ISP or a CDN to have balanced flows at part of a settlement-free peering agreement.


Cloudflare as a CDN with a lot of peering connections likely helps reduce internal traffic for other carriers by virtue of having endpoint data sources close to the destinations of the data.


I wouldn't bet my life on it, but I've never experienced a problem with an IP address ending in 0, and I've been using them for over 10 years. Our primary VPN end-point used to end in .0 - so we had lots of opportunity to find chance for breakage. :-)


I have, actually. Most of our networks were /23s, and the syslog server was a .0 in the middle of one. An SMS sending appliance we bought would not accept IPs ending in .0. Fortunately, the check was client-side in javascript, and once overridden, everything worked.


IIRC, IPs ending in .0 or .255 were unreachable from some older Windows systems.


That's been my experience too.

Even in 2003, the network I was involved in was handing out .0s out of larger CIDR blocks in DHCP leases with no issues.


Anything that cares about the zeroth IP of a destination not on the local subnet is broken. Anything that caters to broken is worrying about the wrong things.


Catering to the broken is like 90% of every developer and data scientist's day.

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.


Jon Postel (who wrote an early specification) of TCP would like to have a word with you:

"be conservative in what you do, be liberal in what you accept from others"


I like the spirit of this, but the problem is that it only works if everyone operates at least somewhat in line with it. If you're liberal in what you accept, then people are going to start being liberal in what they send, and soon we'll have a proper mess on our hands.

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.


Do you have an example? I could possibly imagine this being a problem on a local /24, in that after you apply the netmask the local part is all zero bits. But for a remote DNS server, I cannot fathom how this could be a problem.


r-really? What do people do with routers that use 192.168.1.0?


To potentially clarify here:

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.


> Network: 3.2.0.0 Netmask: 255.255.254.0 (/23) Broadcast: 3.2.1.255

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.


But /27s, or anything from /24 through /30 inclusive, won’t include a .0 or .255 host. Only /23s and smaller or /31 and /32 can have hosts with .0 or .255

Are there any publicly advertised, unsummarised /31s or /32s in the global BGP tables?


You are correct:

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.


> Public BGP requires /24 or wider, and /24 cannot contain .0 or .255 as a valid IP

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.


You can also use a fake IP for the default gateway on a wholly different segment with local segment ARP, or an IPv6 default router with 4-wrapping, or set up a router that uses promiscuous mode to capture all packets it receives from your “default route eth0” host. These are all irregular solutions, though, so I didn’t want to go too deep into the confusing weeds.


It's probably less of an issue when you're on a local network with the device you're trying to connect to. That said, I think 192.168.0.1 (ending in a 1) is much more common.


A /23 with the router in the middle of it? Surely that can't be common. If someone actually chose that (to be annoying or security through obscurity or whatever) then they know what they're doing

DHCP giving out a client address of 192.168.1.0 in the middle of a lagre block sure, but a router?


Routers being the “bottom of the block” in a subnet is just convention. In fact I’d say someone with a router in the “middle” of a block probably knows exactly what they are doing.


And thus would be able to change it if they actually had a problem with ip stacks failing on valid .0 or .255 ips


I'd rather companies like Amazon or Microsoft has them, in a way that people can cheaply rent them along with compute power at competitive rates, than companies like "Prudential" or some giant bank sit on them.


I might be tempted to use 3.1.4.1, or 3.1.4.2, if you round. Or those could resolve to a Raspberry Pi AWS instance :)


I'd avoid the rounding by using double digits...

3.14.15.9


3.141.59.27

But instead I would want a webserver on there that just serves up digits of Pi.


Twist: it serves up digits of e.


Twist: it serves up the first 10 digits of pi followed by e[10:].


Now that's just evil. (Better do it from the 100th digit or so to make it less obvious.)


It opens a stream á la websocket and just pipes digits down.


That would have a different answer based on whether you rounded or truncated. It would be 3.141.59.26 if you truncated.


It would also be 3.141.59.26 if you round half towards even.


It probably wouldn't be better for the health of the internet.

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.


AWS is IPv4-only? Can you elaborate? It seems IPv6 is pretty well supported.

https://docs.aws.amazon.com/vpc/latest/userguide/get-started...


I wasn't implying it was IPv4 only, I was merely teasingly repeating rumors that a lot of low level infrastructure still has IPv4 assumptions that Amazon has had enough IPv4 addresses to date that they don't need fix those underlying assumptions in their data centers. It's mostly dumb rumor mongering, I suppose, as I'm not sure I have a citation for that off hand other than other HN jabs at Amazon/AWS. I'm sorry for that, it was an unnecessary jab/tease, that I will blame on pre-coffee brain.


They used to -- that's why IPv6 was so slow to arrive. But that's fixed now except possibly in some parts of "legacy EC2".


We have IPv4 and IPv6 public interfaces on our AWS services.


The people desperate to use IPv4 are not AWS themselves. AWS doesn't buy stuff just to have it. They buy it because customers are using it. AWS customers are moving stuff out of their data centres and don't know how to use serverless, load balancers, dynamic cloud capabilities (like spinning down instances when they aren't in use) and so on. Customers are doing lift-and-shift in vast volumes and they're doing it in the only way they know how.


This. A lot of those lifted apps will be legacy services built in 2000-2009 that must run 24/7 and only know about ipv4.


Why specifically -2009? What happened in 2010?

(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.)


AWS has heavy support for IPv4 because back-end stuff is all IPv4 and there isn't any push to change. IPv6 doesn't add any real value for servers that are all living in a private address space anyway, it adds an overhead to each packet, and learning off your addressing schemes is far easier with dotted quad.


IP isn’t supposed to have “private address space”. The only reason it does is because the address space is scarce. NAT does not make your network “private” or provide security, firewalls and good host software do that. NAT literally breaks IP.


RFC 1918 (Address Allocation for Private Internets) disagrees with you, and has done since at least 1996.


RFC 1918 describes space for entirely private networks, not “private extensions” to the public globally routable internet. There’s a subtle but important difference. The private addresses strictly aren’t routable on the public internet. NAT (which there’s also an RFC for) is what what allows packets to flow between private disjoint IP networks. IP is only scoped to work within a single network, whether it’s public or private or triangle.


That screws up when two private entities merge and discover that they're using the same RFC1918 block.

(or just want to interoperate, even)


End-to-end principle disagrees with you. As does my network. All routable IP space baby. Makes things a breeze.


IPv6 got a private address space, even if we shouldn't run out of IPv6 addresses anytime soon.


Then what I need is a DNS client on my PC which can use all these major DNS services, but at random to provide incomplete DNS info to any given one, so it'll maybe query any random two, confirm they respond the same to verify nobody's playing unfair.


DNSCrypt-Proxy[1] already supports the randomized DNS resolver need[2]. It also supports DNS-over-HTTPS, providing assurance that even your ISP won't be able to snoop on all of your DNS queries.

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...


DNS servers often return different results to different clients for load balancing, so checking multiple resolvers would lead to many conflicts.


On Linux (and OSX?) you could run a local resolver configured to do round-robin? Comparing answers would probably be new functionality though.


> Then what I need is a DNS client on my PC which can use all these major DNS services, but at random to provide incomplete DNS info to any given one, so it'll maybe query any random two, confirm they respond the same to verify nobody's playing unfair.

What kind of tricks are you afraid of these DNS services could get up to?


Well, DNS is both a significant way one could profile what types of information a given connection is used for and could be used to profile you, so I want to give a DNS provider incomplete information where possible. And as DNS is also a common way to redirect or censor traffic, I feel like there'd be value in a system that would double check that everyone's sending me to the same place. If I get inconsistent results, I could dump both and query two other ones in the pool.


The problem I have there is that Akamai and other CDNs seem to return different results if I'm using my ISP's resolvers vs any others. Getting good local nodes is important in a bandwidth constrained (and far away) environment like Australia.


> Coming soon: Amazon launches free DNS service on 3.3.3.3 and 3.4.3.4?

Do they then cover Seattle in stickers and chalking with 3.3.3.3?


Wish it was 3.14.15.92

-ss


Nah, they'll assign that one to something python related. (Get it? pi-thon. I'll see myself out...)


It would get used up quickly and we'd be right back where we are.


Amazon rank up there just behind Google and Facebook in the list of companies i don't want harvesting any more data from me.


IP block allocation has nothing whatsoever to do with harvesting your data.


Gp was probably reacting to the dns idea.


Amazon is on the extreme end of the customer-privacy side. Wtf are you talking about? If you're going to put them in a bucket, they belong with Apple.


Amazon’s recommendation engine says differently.

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.


Why not 3.0.0.0 or 3.255.255.255 ?


3.0.0.0 is the network address, and cannot be assigned to a host. 3.255.255.255 is the broadcast address, and cannot be assigned to a host.


Both are valid addresses and can be assigned to hosts.

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)


There's no reason why you can't assign 3.0.0.0 to a host, it'll work fine. Just make sure you don't put anything else there by convention.

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.


They delegated 3.0.0.0/15 to Singapore, out of the AWS 3.0.0.0/9 block, which is adjacent to their 3.128.0.0/9 block... which gives them all of 3.0.0.0/8...

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...


I think your statement answers pretty well an observation made earlier: Why is IPv6 adoption so bad? I see little incentive for anyone as long as IPv4 is such a profitable business with IP addresses being traded as an asset. IPv6 and equality to the masses? Would be nice but economy took adifferent turn


I don't think this analysis is correct. Imagine Chrome started charging small amounts of bitcoin for each HTTP request but Firefox still allowed free access. I don't think you'd say "I'm now incentivized to use Chrome because I have to have an artificial scarce resource."

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's fully backwards. The people with the incentive to delay moving to IPV6 are the ones selling IPs. Those buying - ISPs - are also the ones that have the incentive to move to IPV6 as in an IPV6 world, they wouldn't have the spend that money. And ISPs are the ones best positioned for further IPV6.

That IPV6 adoption is slow is precisy because buying ranges of IPV4 addresses is still cheap enough that people are doing it.


ISP are really the bottleneck for IPv6 adoption. Pretty much all the infrastructures of the internet (network, datacentres, clouds) support it now.


When an equivalent solution becomes cheaper that's a recipe for disruption, not the other way around.


Amazon's documentation shows it is already in use on AWS.

They also have 18.128.0.0/9, bought from MIT.

https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges....


And here's a JSON of their IP blocks:

https://ip-ranges.amazonaws.com/ip-ranges.json


I wonder what they got it for? if just for more IPs for AWS stuff, or if it's for something like IoT stuff?


At $18 per IP: 2^24 * $18 = $302mm

At $14 per IP: 2^24 * $14 = $235mm

Price per IP estimated from:

  https://www.ipv4auctions.com/
In 2011, Microsoft paid $11.25 per IP to Nortel for 666k addresses


I bought a /20 in 2015 for $6.00/address. I am feeling very lucky.


How does one buy one? I'm in the eastern Europe.


Very curious as well.


(A /20 is 1,048,576 IPs, so this would have been $6,291,456. OP appears to be a small ISP.)


No, a /20 is 2^12=4096 addresses.


I'm not sure IoT is the best use of a contiguous IPv4 range... you're talking about less than 17 million addresses.

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.


you could make 17 million networks with it, entry point into aws vpcs has to be somewhere


What's up with IPv6, anyways?


Every time I deal with IPv6 it just strikes me how little the designers cared about migration from IPv4.

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.


IPv6 is a total mess; it was intended to be a clean break from IPv4 and do things more correctly. Turns out that they didn't really think it though; besides more bits anything from IPv6 was either easy to add to v4 or turned out to be a bad idea (like SLAAC).

It should never have been adopted in the first place but now it's the only practical option for moving forward.


Enough address space for every atom on the surface of the earth.


And I have a /64 from my ISP giving me about eighteen quintillion addresses, but no sane/supported/easy way to further subnet that locally. IPv6/rfc7421 is great ...


Not quite

https://xkcd.com/865


~~No, really. He's talking about the earths surface, the xkcd is about the earths volume.~~

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


Yet as far as I can tell no cloud provider is taking it seriously.

GCP only supports it on the edge for their load balancers for instance.


IPv6 works fine in AWS. I have several v6 only resources there now... no problems. No SSH scans, no elastic IP fees, no log noise from all the IPv4 idiots. It's heaven.


All rsync.net locations[1] have ipv6 addresses.

[1] Cali., Denver, Zurich, Hong Kong


Been a customer of yours for ten years. No BS. Just works.


So abundant, has no value.


I would say "no cost".

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 ?


I'd love to use it, but honestly it's fairly complex to even understand if I can use it. From my home ISP to my compute provider(s), I've not even done enough research to know if I can use 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.


I'm a current Comcast customer. I own my own (non-Comcast-purchased) router (an RT-AC68U) and cable modem (a Motorola Surfboard).

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


IPv6 is interesting, https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/confi...


If I'm at home and my computer has an IPv6 address, and I want to visit a site that has only IPv4 address, where does the NAT happen? Or does it happen? Or is it sort of like ASCII in UTF-8; all IPv4 addresses are directly representable in the IPv6 format? But even if that, how does the IPv4 service send a response back to me?


At home you will be "dual stack". That means your operating system implements an entire IPv4 network stack and an entire IPv6 stack, it will see this site only has IPv4, and use IPv4. If your IPv4 access goes through a NAT, then it will use the NAT exactly as if you didn't have IPv6 at all.

(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.


Wouldn't it have been nice for IPv6 to provide a basic translation protocol or mapping for seamless migration and backwards compatibility? Where your IPv4 address is also an IPv6 address?

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.


This was done, it was called 6to4 and it worked pretty well when native IPv6 was less available. The gateways had an anycast IPv6 address too so you didn't have to manually configure the address of your gateway to the real IPv6 internet.


As an example, if we look at https://github.com/GoogleCloudPlatform/container-vm-guestboo... then there are a couple of things here that are IPv4 only. The first is that the application is only configured to listen on the IPv4 address family, app.run(host='0.0.0.0', port=80), on linux if that was changed to app.run(host='::', port=80) this the application would be able to receive both IPv4 and IPv6 requests (on windows the situation is different however) The second, and less important change, is that the redis connection is using 127.0.0.1, and if instead it was using "localhost" then that would resolve to the correct address family. This is less important as it is only relevant if there is no IPv4 on the server host, the first change would allow your app to accept IPv6 traffic.

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.


From your point of view it will "just work". One day you'll get an IPv6 address, if you haven't already, and it will look and feel identical to your IPv4 address. So I wouldn't worry about it.

(As a comcast customer that "one day" for me was several years ago)


I had an IPv6-only host last year, sucked that I couldn't clone my dotfiles from github - because they were IPv4-only.

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.


Adoption rate varies from country to country: https://www.google.com/intl/en/ipv6/statistics.html


It's interesting to note there's a definite variation on a 24-hour cycle... because there's a correlation between longitude and IPv6 adoption...?


Corporates. At work your network is IPv4 only, it passes through a badly made "anti-exfiltration" appliance, a "policy enforcement" appliance and half a dozen more, you have that six year old laptop that's missing some crucial patches because they were incompatible with the Java applet used to order coffee in the board room, and so on.

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.


It's on a weekly cycle, with peaks presumably on the weekends. Maybe more home internet connections than workspace internet connections are IPv6, so there is an uptick in registered IPv6 connections when people are at home. (Note how the trough between Dec 24th and 31st is also significantly more shallow than the usual one.)


IPv6 adoption is approaching a big wall. Maybe the industry will finally start reconsidering it and doing honest research into something that can actually get wide spread adoption.


There is no magical ipv4 compatible protocol that is possible at scale that is simply being denied to the masses by the Ivory Tower IETF.

IPv6 is the future of IP connectivity, that is not going to change.


How so? There is unlimited amount of compatible protocols that can be made to run on top of IPv4.


And they all suck in various (usually non-obvious) ways.


That's the thing. Any idea done in software on top of existing ones sucks infinitely less, than any incompatible idea backed by hardware.


Here’s the thing - all the hardware supports it now. Has done for the last couple of decades. Your home router almost definitely does, your carrier’s switches and routers almost definitely do, there’s ipv6 support all the way to Google and Amazon and Netflix and whoever else you want to connect to. It’s a pile of people refusing to implement software (mostly proprietary software - again, open-source systems have supported IPv6 for a very long time) and administrative support for it that’s the issue.

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.


IPv6 is software in almost all implementations, just like IPv4.


Not actually true. There are plenty of hardware L3/4 switching/routing/flow acceleration chips. IP4 is fast on 32bit machines but IP6 is 4 times the word size there. Hardware does matter.


Yeah, it exists in hardware implementations too, but most devices that have IP stacks (of either IP version) do it in software because they're general-purpose computing devices.

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.


How does that solve anything? If you still need an IPv4 address, what's the point?


You don't need a routable IPv4 address, only your ISP needs it. Think overlay networks.


So, NAT? We already have that, no need for new protocols.


Imagine an overlay network that consists of nodes running directly on end users' computers. It has its own routing system and it can establish connections to other nodes via local network, via internet, punching holes through NAT, etc. If popular things like web browsers implement support for that overlay network, ISPs don't even have to provide NAT or routable IP addresses to customers that want to access the web, they can just run some nodes themselves that have internet connectivity and expect end users' nodes to find those nodes over local network and get web connectivity over that overlay network. Of course there are no limits of how integrated overlay networks can become. But notice how little change overlay networks can be made to impose on everyone and to support effortless gradual transition.


You can already use ipv6 as an overlay network ontop of ipv4 and not worry about whatever wacky shit middle nodes are doing

https://tunnelbroker.net/

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.


Except educating users on how to install their overlay network of choice.

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!


Web browsers could bundle everything with the next update or use the one already installed, see tor browser bundle for example. No need to educate users. Other software could rely on preinstalled daemons and guide users to "install the internet" on first use if necessary.

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.


How is this any better than IPv6? Each browser having its own overlay sounds like the good old days of AOL.

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?


We needed a few static ipv4 addresses for interconnects.

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.


I haven't worked much in IoT but I kinda assumed devices get private IPs on whatever LAN and phone home to traverse NAT.


[flagged]


Correct strategy in the case of early down votes that you think are incorrect is (1) review what you wrote to see if its tone was flame-bait; (2) wait it out quietly until votes equilibrate. Usually something reasonable comes out over time.


Yeah, that seems like a better strategy than a salty comment, which almost always just gets downvoted too.


Meh, HN seems to hate questions when they think the questioner isn't genuine: Basically if they wish the answer weren't true. That's been my recent experience anyway.

Better suggestion - stop politicking and answer the question or move on.

Sure if the question is badly made then downvote it. Whilst downvote for disagreement is encouraged here (by the site owners) you can't "disagree" with a question, that's nonsensical.


Downvoting for disagreement is encouraged? That's news to me! Not welcome news either, because I like the idea that the "quality" of the comment matters more.


Personally, while I don't downvote for disagreement, I definitely will downvote (what I perceive as) disingenuous questions — There's more productive ways to express an opinion.


pg (the site's creator) once wrote that it's ok[1], and the current mods have cited that post recently[2], indicating it's still the policy.

[1] https://news.ycombinator.com/item?id=117171

[2] https://news.ycombinator.com/item?id=17996858


I make a habit of commenting if I downvote, sure, the commenter might not like what I have to say but I feel I owe it to them to be as honest about why I felt they weren't contributing to the discussion.

To answer your question: "how can you disagree with a question"; well, you can downvote a question that is loaded (with some kind of ignorant agenda) or a question that is so blisteringly ignorant by itself that it is plain and obvious that the commenter didn't read the article posted, even a skim-read.


Downvotes just happen on HN, no need to let it upset you. I have a theory that some anarchists have bots running that just downvote new comments in an arbitrary pattern. You know, to keep things perfectly balanced, as all things should be. Similarly I wrote a Chrome extension that may or may not hide the top comment on any given HN post. Keeps you on your toes. https://github.com/sdegutis/PerfectlyBalancedHN


I actually wrote a script to track this and it's been running for a few months.

I generally post around 9am and 12pm US east coast time. When I take a substantial negative hit it's around noon or 3pm on the East coast. There's a baseline amount of up-votes and down-votes (with up-votes dominating) that seems to roughly correlate with the hours most people are awake in the US and Europe.

Someday I'm going to publish a write-up here.


What's the conclusion? Seems to me like it could be that it's near the end of the work day for most casual HN readers and they're cranky (low blood sugar from a standard American diet) so they downvote whatever they see?


Probably because the answer is obvious: AWS. Just do a "whois" on 3.0.0.0 and you'll see the contacts are for AWS EC2.


Truth hurts, that's why you get downvoted.


Given that IP is a scarce resource, why aren't we taxing those large IP blocks similar to property taxes on land? If holding an /8 came with a hefty tax bill attached, it would 1) encourage companies that got them for historical reasons and don't have much practical use for them to sell them to those who actually need a lot of IPs, and 2) encourage IPv6 MIGRATION.


Who do you pay the tax to? Be warned that your answer will probably lead to a fragmented Internet, or encourage even less redistribution according to real needs


Isn’t there a misalignment between IPv6 adoption and scarcity of IP addresses? We rely on ISPs to adopt IPv6, but if they also own IP space, why would they lower the value of their holdings.


Does anyone mind sharing how IP addresses are allocated and bought in the first place? Like who did GE buy it from if it wasn't another company?


In the very early days no one understood that over half of all humans would be on the internet. It was just this ARPANet thing for the military and universities, then a few big companies.

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.


And oddly enough, this seems to be happening all over again with ipv6.

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.


They thought of that; the current allocation scheme will be used for IIRC only 1/8 of the IPv6 address space. If that's ever exhausted, there's still the other 7/8 which can be allocated in a more conservative manner.


People start encoding information in IPv6 addresses because the address space is so huge. This however, could lead to address shortage.

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...


Yeah, we can only give out 4,294,967,295 more /32s to large companies.


So to take a known scale, there is not enough to give one to each person alive. Which might seem crazy but then again, why would everyone not only need an ipv4, but need several (phone, computers, watch, tv,...)? Crazy


That seems wasteful, but that is the equivalent to getting a single IPv4 address by asking for it, and the IPv4 shortage wasn't caused by the distribution of individual addresses. It's a world of difference to getting a /8 by asking for it.


We would still have ipv4 shortage that way though, not enough to give one to everyone, let alone the several we need. Same here, this might seem a crazy problem to worry about, but they're handing out ranges of size large enough that there isn't enough to give one to any person alive.


Apparently not for every atom. The space is small enough to save us from grey goo scenario, at least until nanobots invent NAT.

https://xkcd.com/865/


I believe it's more like every atom in the universe. Which means that inherently it is enough. But indeed it is still best to be somewhat careful.


There were always yearly fees; it's just that prior to 1995 they were paid for by the US taxpayers instead of the domain owners.


Those literally weren't fees. The dictionary definition of fee is "a payment made to a professional person or to a professional or public body in exchange for advice or services".

Hence, there were no fees. Stop engaging in pointless (and even incorrect!) sophistry.


Definition 1.1: "Money paid as part of a special transaction, for example for a privilege or for admission to something." I'd say that applies.


Those literally were indeed fees.

The National Science Foundation paid Network Solutions a payment, per registered domain, in exchange for the service of registering it.


IP-Addresses and domain-names are only tangentially related. Just because you pay a fee per domain-name does not mean it's the same for network addresses.


My comment is addressed at "Same goes for DNS. You used to request the name and it was yours. No yearly fees."


> Originally a file named HOSTS.TXT was manually maintained and made available via file sharing by Stanford Research Institute for the ARPANET membership, containing the hostnames and address of hosts as contributed for inclusion by member organizations.

https://en.m.wikipedia.org/wiki/Hosts_(file)


And where do you think the money to pay the ARPANET contracts came from?


Well, in case anyone was wondering, the answer is US taxpayers: http://www.columbia.edu/~rh120/ch106.x07


Sorry. Didn't catch the context.


The cost to run the DNS servers was fixed (and mostly still is, at least compared to the money raked in by registration fees).


That's both untrue and irrelevant to this discussion.


The IANA was responsible for assigning IP addresses back then. It was basically one dude, Jon Postel( https://en.wikipedia.org/wiki/Jon_Postel ), until it was formalized as an organization in 1988.


s/basically one/one amazing/


The foundational work he did was definitely impressive. But the fact that it fell to one guy also spoke to how low the stakes were at the time.


I researched it, and I don't have the specifics in front of me, but it looked like a massive corporate giveaway.

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.


Back then I don't think anyone ever considered we'd use up the IPv4 address space and/or assumed that the migration to IPv6 would happen more more quickly, rendering IPv4 obsolete. It looks like most of the big blocks were all assigned prior to widespread consumer internet adoption.


Back then IPv6 wasn't planned at all. By the time the need for more address space was realized, v4 addresses were already a valued commodity and no longer given away on request.


It's worth noting that at the time for the value of an IP address block was pretty much 0.


IBM owns 9/8 - it's used for their internal network (really). They're mid-way through a 2y project to move everything to IPv6

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'.


Can someone give an ELI5 summary on why this is important and has 360+ upvotes? Why would GE have had this? Why did Amazon want it?


3/8 or 3.0.0.0/8 means the IP address range from 3.0.0.0 to 3.255.255.255 - this is 2^24 or 16.7M IP addresses.

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.


Does that mean Amazon has a lease from ARIN on those batches of IPv4 addresses for a period of time (in the same sense as a domain registry for x years) or actually own them?

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.


IP Address purchases one-time purchases, you don't pay annual fees.

There is another comment here that said Amazon paid ~18/IP. They won't pay this next year.


Historically, 32-bit address space was large on the fledgling internet. It was relatively easy and cheap/free to get a /8.

Amazon probably wants it to sell to their customers who need ipv4 instead of v6


Amazon own the largest public cloud provider (AWS). Assuming they use it on this, it makes sense they'd want a bunch more IP addresses.


Can someone explain what /8s /16s etc. are? Or a link to a good explainer?


It tells you how many of the 32 bits in your IPv4 addresses are fixed. The rest belongs to your space.

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.


They are subnetwork masks! It's a formal way of expressing in which range you will find the addresses of a given network (for example: 3.0.0.0/8 is like saying "3.x.x.x addresses"; or, for common home networks you will find something like 192.168.1.0/24, which means "192.168.1.x"). I'm not an expert on the subject, but this site seems to have a complete explanation: http://www.steves-internet-guide.com/subnetting-subnet-masks...


I believe it means that this block is 1/2^n of the total address space. Basing this off people discussing how this /8 is made up of two /9s. And there seems to be 256 of the GE sized blocks in the map someone posted above: https://www.caida.org/research/id-consumption/whois-map/imag...


It's called CIDR notation. https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing


Go to http://cidr.xyz Try out different combinations


https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing


When we were hp we used to own all of 15.0.0.0 and 16.0.0.0 (formerly DEC) but now we're down to only 15 and hpe has 16. It's weird how these blocks move around, should really be more of a shared resource.


As an individual, I own an entire /24, registered back in 1993. The people who got in early got a disproportionate amount of address space. New ISPs / companies have to beg and borrow just to get a small slice.


This is happening with IPv6. People think there's so much address space that wasting several trillion isn't going to matter.

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)


Perhaps the visualization here would show you just how huge IPv6 space is.

https://subnettingpractice.com/ipv6_is_huge.html


By the way, I always wondered what if companies start acquiring large IPv6 space chunks, and it will become the same problem as with IPv4. For example in hand, if AWS bought 3.0.0.0/8, cannot they buy 03::?

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.


No, because all global unicast allocations are done out of 2000::/3 This means even if we screw up all these allocations, we have many other chances to get it right.

See https://www.iana.org/assignments/ipv6-address-space/ipv6-add...


You don't just buy blocks. You get assigned them, based on evidence of need.

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.


I owned a couple /24s around then as well, but I'd completely forgotten about them until now. I never even used them because it was a hassle to get them routed. I assume they've been reallocated by now, but I'm not sure. I don't have access to the [email] domain I registered them from (nor am I even sure what it was at the time).


It is likely they were not reallocated... Any idea what the ranges were or the names you registered them under? You might be able to dig them up with brute force whois or some google searches...


I believe just under my own full name, although I may have specified an organization. If there's no ongoing maintenance requirement to retain IP allocations (like an annual fee), then maybe they are still floating out there attached to me in some way. I'll have to do some research.


For "legacy" space, meaning anything predating ARIN (before 1997-ish), no fees are required unless you chose to sign the registration services agreement. I refused to sign it and my /24 has remained free for the past 25 years.


Have you ever looked into what you'd get from selling it?


Probably $5K/ish. I have it routed... I have a couple of personal machines off of it.


That's a really cool fun fact to share about yourself. I'm jealous!


I'm think if you can reasonate with a hosting provider (big name ones), you can have a /24 block for yourself. You better have a great reason, and be prepared to pay ~$3/ IP.


I am curious, can you rent it?


Yeah, I could. I'd rather use it myself though.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: