Live data from Hacker News

AWS adds an extra 5.5M IPv4 addresses

github.com

171–180 of 283 posts

Re: AWS adds an extra 5.5M IPv4 addresses

#171
post #146

Earlier quoted context omitted.

All this is because IPv6 addresses are too long. If they’d made it 48 or 64 bits we would be fully converted by now. We are dragging because people hate using it. I’ve been saying this for years. Nobody gets it because geeks don’t get ergonomics.

I've said it for years too. It's not JUST because they're long - years ago (and maybe even today?) there's still some hardware issues with keeping large sets of addresses for routing (I'm not an expert on this - I seem to remember reading about this years ago - larger ISPs not being able to keep all their routing rules in memory because of IPv6 address sizes - maybe I'm WAY off). But, yes, generally, you're right. It…

In designing ZeroTier I put a ton of effort into creating a secure P2P layer with addresses that are only 40 bits long. This effort continues with new solutions being worked on to maintain security while allowing more openness and federation.

It would have been much easier to use long addresses that are long hashes of keys. Having only 40 bits means we need two layers of defense in depth to prevent intentional collision: a work function to make the cost substantial (about USD $8M per collision on today’s public cloud) and a single source of truth for lookup that still supports federation. You could punt on all that with 128 or 256 bit addresses.

Yet I did it because I was quite aware that it was very necessary for usability. I have had many people tell me they love that they can type a ZeroTier address.

I would bet anyone that if the addresses had been gigantic we’d have 1/10 the adoption.

Software is first and foremost for people to use. Most of the complexity in software exists for this reason.

Re: AWS adds an extra 5.5M IPv4 addresses

#172
post #146

Earlier quoted context omitted.

All this is because IPv6 addresses are too long. If they’d made it 48 or 64 bits we would be fully converted by now. We are dragging because people hate using it. I’ve been saying this for years. Nobody gets it because geeks don’t get ergonomics.

I've said it for years too. It's not JUST because they're long - years ago (and maybe even today?) there's still some hardware issues with keeping large sets of addresses for routing (I'm not an expert on this - I seem to remember reading about this years ago - larger ISPs not being able to keep all their routing rules in memory because of IPv6 address sizes - maybe I'm WAY off). But, yes, generally, you're right. It…

> (I'm not an expert on this - I seem to remember reading about this years ago - larger ISPs not being able to keep all their routing rules in memory because of IPv6 address sizes - maybe I'm WAY off).

in modern (last 10 - 15 ish years) routing table size has been roughly the same for IPv4 and IPv6.

Modern, ISP grade routers have control and forwarding planes seperated between different (usually redundant) hardware components. The control plane is responsible for keeping states of routes (which routes do i recieve from a routing protocol? where is my next hop according to rule XYZ etc). Forwarding plane is responsible for forwarding packets across interfaces.

Route lookups happen in the control plane, but a route lookup is almost never for a dedicated address (especially in IPV6). route lookups happen at the subnet level, and IPV6 has a "standard" subnet size which leaves half of the address space for the subnet itself. (the first /64 subnetmask bits are used for network differentiation, while the other /64 is used to create host specific addresses).

This cuts down on TCAM size considerably, because the router doesn't need to store 128 bits of information per host, but only 65 bits + subnetmask for a very large group of hosts.

besides this, IPv6 has another advantage because fragmenting routes is far more difficult then in IPv4.

Usually, organisations get a /56, the ISP usually handles /48's and RIPE/IANA etc work with /32.

This all keeps the IPV6 routing table far smaller then the IPv4 routing table, which was one of the reasons IPv6 was invented in the first place.

> But, yes, generally, you're right. It's been seen from the very beginning as "a big move". If every address A.B.C.D was addressable as 0.A.B.C.D, and we opened up another 255 * 4 billion addresses... we'd have been converted a long time ago. And we'd have been better at actually implementing 'upgrades' because they'd be already done/completed - it wouldn't be a 'monumental task(tm)'.

would this actually change the amount of "momumentalism" in switching ipv4 for something else? Backwards compatibility with larger address sizes (be it 128 bits, 33 bits or whatever) is not possible because ipv4 stacks can only hadle 32bit address space. Updating those is about as a monumental task as implementing IPV6, considering you would still need two network layer stacks for each device to handle both IPv4 and the "ipv4+" version.

Re: AWS adds an extra 5.5M IPv4 addresses

#173
post #146

Earlier quoted context omitted.

All this is because IPv6 addresses are too long. If they’d made it 48 or 64 bits we would be fully converted by now. We are dragging because people hate using it. I’ve been saying this for years. Nobody gets it because geeks don’t get ergonomics.

I've said it for years too. It's not JUST because they're long - years ago (and maybe even today?) there's still some hardware issues with keeping large sets of addresses for routing (I'm not an expert on this - I seem to remember reading about this years ago - larger ISPs not being able to keep all their routing rules in memory because of IPv6 address sizes - maybe I'm WAY off). But, yes, generally, you're right. It…

> If every address A.B.C.D was addressable as 0.A.B.C.D, and we opened up another 255 * 4 billion addresses... we'd have been converted a long time ago.

That has nothing to do with the address being long, but with being compatible.

Re: AWS adds an extra 5.5M IPv4 addresses

#174
post #86
post #16

Earlier quoted context omitted.

Public auctions (which they didn't use) are currently in the $45-50 per IP ballpark. At that price it's $247.5 million worth of IPs. At auction the larger networks tend to go for less money per IP since there is a smaller market of people who want and can buy them (you have to be approved by ARIN/RIPE/etc. for the allocation size), which drives the price down.

That’s not actually too expensive, considering they make that money back in a few months if all those IP’s are hosting even their smallest server.

It's not like the news of "we have new IPs" instantly drive customers to rent more VMs. They are likely to have a lot of unused capacity for years, which is not paying back for itself.

Re: AWS adds an extra 5.5M IPv4 addresses

#175
post #77
post #61

Earlier quoted context omitted.

And law enforcement inquiries barely contain source port information, or precise time. Most of then go like: who had this IP in $this-two-weeks-window. No source port, no destination IP/port.

"We don't have the ability to determine a specific subscriber based on the information provided" and close the request.

this is not how most of these laws works. As an ISP, you are required to have this bookkeeping, and are audited for it in (most) countries.

Usually, the law has specific procedures about how this information is requested, what responsibilities are with which party, and how long the response time should be for suchs a request.

When starting (or already being an ISP). You already know what kind of system you need to build that matches all these requirements by law. Simply saying, we do not have the required information wouldn't work because the law has very specific details about the requested information.*

* this is in a european country, so no clue if this is applicable to the US.

Re: AWS adds an extra 5.5M IPv4 addresses

#176
post #58

Earlier quoted context omitted.

Controlling 200 times more of a critical resource than the next competitor does not sound like healthy competition.

That's if you can define IPV4 as a critical resource. But because anyone can assign any IPv4 address to anything and advertise it with BGP, it can't fit the definition of that.

There would be penalties for that, maybe even legal ones. How easy it is to steal does not really factor in whether it's a critical resource.

Re: AWS adds an extra 5.5M IPv4 addresses

#177
post #176

Earlier quoted context omitted.

That's if you can define IPV4 as a critical resource. But because anyone can assign any IPv4 address to anything and advertise it with BGP, it can't fit the definition of that.

There would be penalties for that, maybe even legal ones. How easy it is to steal does not really factor in whether it's a critical resource.

Can it be defined as property? I could make a Internet The Second using isolated networks and advertise whatever I wanted. It's not like digital movies and music where it's defined as property under copyright law because it's a creative work.

Re: AWS adds an extra 5.5M IPv4 addresses

#178
post #162

Earlier quoted context omitted.

That's like saying that private property is worthless because the state can take it from you by force. Technically that's correct, but if that generally doesn't happen then it's not something we have to worry about.

Can IPv4 even be defined as private property if it is nothing more than a few DDN numbers? I could make a Internet 2 that's totally isolated and restart the whole IP allocation process all over again.

Given there is such a thing as intellectual property, where someone literally owns an idea, I'd say owning an address isn't far-fetched at all.

Re: AWS adds an extra 5.5M IPv4 addresses

#179

Earlier quoted context omitted.

Problem with CGNAT is the costs involved in bookkeeping for law enforcement. Where an IPv4 solution for your clients only needs change-logging on IPbinding-to-client level, the CG-NAT requires you as an ISP to log every outgoing IPv4/port combination with timestamp to client mapping. Which requires A LOT more storage and much more expensive equipment. Going rate per IPv4 is up to $40 nowadays, selling of your v4 bloc…

I'm finding more and more that I go to some random website, and get a message about an IP ban. That or a 401 error with no context. If cgnat keeps scaling, these ip Limiters need to phase out.

> If cgnat keeps scaling, these ip Limiters need to phase out.

This problem would be easy to solve, if only there were some way for a website operator to phase out CGNAT and see a user's 128-bit IP address instead...

Re: AWS adds an extra 5.5M IPv4 addresses

#180

Meanwhile, Hetzner just added a staggering $19/address setup fee and a soon doubling of prices for IPv4 addresses from them ostensibly due to the rising costs of getting addresses, yet still has virtually no support for IPv6 on their offerings outside of a /64 per dedicated server. https://docs.hetzner.com/general/others/ipv4-pricing/

/64 seems pretty standard, unfortunately. It's what I get on OVH. There's also way worse providers, like Digital Ocean with a /124, and LightSail with /128.
Post reply on HN