Live data from Hacker News

AWS IPv4 Estate Now Worth $4.5B

toonk.io

291–300 of 480 posts

Re: AWS IPv4 Estate Now Worth $4.5B

#291
post #116
post #103

Earlier quoted context omitted.

Only network engineers should see or care about IP addresses. The fact IPv6 addresses use colons is why people don't use IPv6 is the worst take I've ever heard.

But only network engineers pick the protocols used. You’re making life harder for the very people who should be your primary audience. PS: As a developer, I often read logs and go ”oh yeah, that’s just our satellite office IP”. 192.168.1.110 is the network printer, etc. There’s no hope of recognizing IPv6 addresses at a glance the same way.

Maybe if you only have five VMs or something, but when there are 100 or more the additional bits in an IPv6 address will be useful. You can recognize a whole subnet as dev, or production, or a different site, or the office LAN.

Re: AWS IPv4 Estate Now Worth $4.5B

#292
post #195
post #114

Earlier quoted context omitted.

How do you not break compatibility with IPv4 while also getting more bytes in the address?

Maybe just don't? Let it be IPv4 with more bits, the software is already there so dual stacking isn't so bad, adoption might actually be quick if people didn't have to learn much to implement it.

>Let it be IPv4 with more bits

Then it's not IPv4 and is not compatible with IPv4.

Re: AWS IPv4 Estate Now Worth $4.5B

#293

Earlier quoted context omitted.

>”So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure.” So… NAT.

No. There would be no NAT box holding IP-port mappings in its internal memory, with the related timeouts, flakiness, port clobbering etc. and no packet re-writing. All routing decisions would be static, based on information in the IP header: the legacy outside routers would just examine the legacy part of the IP address and packet, while the internal IPv4.1 would use the extended bits. So just like any packet routing…

It sounds nice on paper but typically we don't want unsolicited packets to reach internal hosts.

Yes, NAT is not a firewall --yet we don't see admins eager to put random lan hosts in the DMZ or enable UPnP.

Re: AWS IPv4 Estate Now Worth $4.5B

#294
post #237

Earlier quoted context omitted.

You say ipv6 was supposed to get rid of NAT. Can you explain why it doesn't? You then say the problem was built into ipv6 from the start. From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.

The existence of NAT66 and NPTv6 are proof that there is still a need for NAT in an ipv6 environment. Maybe not in your environment, but people wouldn't make these solutions if there wasn't a need.

One such use case: multi wan routing.

Would you rather have a bunch of routers sending out advertisements which every client needs to sort out, or have one consistent multi wan load balancing/failover policy that is transparent to clients?

Re: AWS IPv4 Estate Now Worth $4.5B

#295

Can we go back in time and hit the designers of IPv6 upside the head? The decision not to make IPv6 backwards compatible, the belief that a beautiful new standard could magically replace something already so widespread... "Naive" is an inadequate word. We are still futzing with the transition 3 decades later, with no end in sight. Grrr, grumble...

These arguments always boil down to these two: "Please just try to fit more than 4 billion numbers into 4 bytes" -- this is mathematically impossible. "Just extend the address size" -- this is an entirely new protocol by the definition of IPv4, which uses fixed-size addresses. The reason for the slow IPv6 adoption is that there was no financial or business pressure. While IPv4 is ubiquitous, nobody individually feels…

We could presumably have done something like: use the IPv4 packet format, treat the 32 bit src/dst address in the header as the first 32 bits of the address and put the remaining 96 bits (+ checksums/etc.) as the first few bytes of the payload. Then create TCPv6, UDPv6, IGMPv6 etc. protocol identifiers for the protocol field to distinguish traffic that's encoding an IPv6 address in the first few bytes of the payload.

Then, if you own an IPv4 address, you effectively own an IPv6 subset. Then we reserve a whole bunch of IPv4 addresses for IPv6-only allocations.

I obviously haven't thought it through in detail, but wouldn't something like that effectively transparently work via IPv4 core infrastructure provided the networks at either end support IPv6 if they're using it? We'd still need NAT for IPv6-only endpoints that need to talk to IPv4-only endpoints. It also wouldn't be anywhere near as clean as IPv6 and would lack a few of the nice features, but... an awesome protocol I can't actually use isn't much use to me.

Re: AWS IPv4 Estate Now Worth $4.5B

#296

Earlier quoted context omitted.

No matter what change you make, or how you make it, if you are making more than 4B addresses routable then any existing IPv4 device will not be able to route some addresses, so you will have caused a split in the internet This is a fundamental and unresolvable problem with "making it backwards compatible"

Wouldn't NAT be an existing and well used solution to this problem?

NAT is the problem that IPv6 fixes. Think about the parent comment

>if you are making more than 4B addresses routable then any existing IPv4 device will not be able to route some addresses, so you will have caused a split in the internet

This has basically already happened. We've massively extended IPv4 by stuffing extra address bits into the router's port number, and it means that any two devices behind NATs can't directly route to each other.

Re: AWS IPv4 Estate Now Worth $4.5B

#297
post #33

Earlier quoted context omitted.

Debian would just not run due to apt repositories being borked if ipv6 was turned on.

Which exact repo was that?

I seem to think that the primary UK mirror (http://ftp.uk.debian.org/) was problematic for v6 for a while? But these days the https://deb.debian.org/ mirror is really heavily pushed, and that one seems to work just fine.

edit: but this was quite a few years ago, from grepping my IRC logs, somewhere around 2016!

Re: AWS IPv4 Estate Now Worth $4.5B

#298
post #239
post #224

Earlier quoted context omitted.

Its a /48 for IPv6. Thats what I have in my RIPE Account.

As I understand it, the current policy allocates /48 for special purposes. Normally allocations that small are supposed to come from an LIR, not directly from an RIR.

I was sponsored by a LIR for RIPE, but RIPE is the entity that gives out the /48 for me specifically. Its still PI space that I can announce with any ISP.

I could request a /32, but a /48 is definitely enough for me. Might request a second /48 at some point maybe.

Re: AWS IPv4 Estate Now Worth $4.5B

#299

Earlier quoted context omitted.

> but it keeps not happening The article you're responding to is a dramatic demonstration that it has happened: Amazon's IPs would not be worth $4.5B if we hadn't run out. It requires us all to ration a resource (namely numbers) that should be near-infinite and essentially free.

> It requires us all to ration a resource (namely numbers) that should be near-infinite and essentially free. There can only be ~4.3 billion IPv4 addresses, which means that mathematically IP addresses are severely limited - you can't assign even one single globally routable IPv4 address per human. That's why we have NAT and its evolution CGNAT in the first place.

That’s their point, if there were more addresses we wouldn’t need to

Re: AWS IPv4 Estate Now Worth $4.5B

#300

Earlier quoted context omitted.

This is one of the reasons why I'm trying to avoid Github these days. If they can't get something as simple as IPv6 to work, I don't have much faith in the test of their backend either.

Sort of a weird take. I doubt if the people responsible for testing their backend have ever even met the people who would migrate to ipv6

There's plenty of attention on the Github meta issue about the lack of IPv6 (https://github.com/orgs/community/discussions/10539) so anyone who even glances at customer requests should be aware of the issue at the very least.

They also did offer IPv6 availability for a short while as a test, but that was quickly shut down, so there is probably a technical issues they can't figure out or they would've kept the trial system running for longer.

Either way, Github isn't communicating, so it's hard to tell if this is indifference or incompetence. As an end user, the distinction doesn't really matter.

Post reply on HN