Live data from Hacker News

AWS IPv4 Estate Now Worth $4.5B

toonk.io

441–450 of 480 posts

Re: AWS IPv4 Estate Now Worth $4.5B

#441

Earlier quoted context omitted.

I understood djbs article differently then you. What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other."? But maybe I should reread the article a bit more generously…

You're picking a brief and vague 1-sentence summary he wrote, and missing everything that came after it that explained in detail what he's talking about. > What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses." He could've meant "making IPv6 work means much more than upgrading software . Every administrator of a…

I have read all of it and I don't agree with you. But lets roll with your interpretation.

Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity.

All those other things you would still have to take care of even if you magically could keep using the IPv4 address in IPv6 (however that would work). Never mind that servers don't statically sit around forever, but one has to set up new servers all the time.

So why not go for the inverse approach for new servers? Only give the servers IPv6 addresses and for those servers that still need to be reached via the public IPv4 internet (most internal ones probably have no need of this) can be accessed via SIIT, which performs stateless mapping between IPv4 and IPv6 (for example IPv4 1.2.3.4 gets translated to IPv6 2001:db8::1.2.3.4 and vice versa).

Re: AWS IPv4 Estate Now Worth $4.5B

#442
post #350

Earlier quoted context omitted.

There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase. So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure . So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks suc…

> There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase. That is called DS-Lite and we have it Still doesn't solve a problem of old clients not being able to access new servers

> That is called DS-Lite and we have it

No. DS lite is a technology that allows the ISPs to upgrade to IPv6 while their clients do not. This is not the problem preventing IPv6 adoption, quite the contrary, clients support IPv6 from the Windows 2000 and Linux 2.1 era. What held back adoption is precisely that most ISPs don't bother with IPv6, which is an extra headache in configuration and man hours, as long as it provides no benefit to the end user.

The beauty of a backwards compatible packet format is that it takes the last mile ISP completely out of the equation, clients upgrade when they see benefits, and instantly get end-to-end connectivity. This is important for VoIP, push to mobiles etc.

> Still doesn't solve a problem of old clients not being able to access new servers

See sibling comment on why this is not the right problem to solve either.

Re: AWS IPv4 Estate Now Worth $4.5B

#443

Earlier quoted context omitted.

You're picking a brief and vague 1-sentence summary he wrote, and missing everything that came after it that explained in detail what he's talking about. > What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses." He could've meant "making IPv6 work means much more than upgrading software . Every administrator of a…

I have read all of it and I don't agree with you. But lets roll with your interpretation. Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 conne…

> I have read all of it and I don't agree with you. But lets roll with your interpretation.

You don't need to agree with me on what he's saying. The quote "...extra effort to acquire and enable a public IPv6 address" is a directly copied from his own page. It doesn't make sense to read that and claim that's not what he's saying, or to claim I'm "interpreting" it to mean that. That quote is what he's saying.

> even if you magically could keep using the IPv4 address in IPv6 (however that would work)

It's not magical, I explained it in [1]. And he himself started to explain it when he wrote "The specifications could have [...], but they didn't", but he didn't finish the thought, and just left the reader to figure out the rest of it. (Which, again, I explained in [1].)

> Adding the address to the server is the easiest part of the whole process.

The issue isn't "adding the address to the server". The issue is obtaining said address to be able to add it to the server in the first place. This requires both you and your ISP to set up and manage/maintain an entirely independent parallel network with an entirely separate configuration. It's an administrative hurdle, not merely a technical one. I can't explain it better than this user did, so just read his comment [2].

In any case, it's fine if you disagree that this is actually a significant hurdle; I'm not trying to argue that point. My goal here was to portray what djb is saying accurately, not to agree or disagree with it. So if you disagree with it, that's mission accomplished (for me anyway).

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

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

Re: AWS IPv4 Estate Now Worth $4.5B

#444

Earlier quoted context omitted.

There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase. So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure . So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks suc…

You can tunnel IPv6 over IPv4 (which is how the very first deployments worked). And I think 6to4/6rd worked pretty to close to what you suggest: Each IPv4 gets assigned a block of IPv6 space which gets tunneled over IPv4.

> I think 6to4/6rd worked pretty to close to what you suggest: Each IPv4 gets assigned a block of IPv6 space which gets tunneled over IPv4

No. Tunnels encapsulate IPv6 traffic but they need to be set up, I need to know a gateway that is willing to take my traffic, decapsulate it and place it on the IPv6 internet. There are many reasons this is bad idea, it won't ever scale, it's fragile etc. 6rd doesn't improve things significantly.

A backwards compatible packet format will allow you to connect directly to IPv4.1 islands, without any configuration or choke point: the packets you place on the wire have the final extended structure, even if they appear as encapsulation to the legacy IPv4 hosts in the path.

It's as if any IPv6 host on the internet is guaranteed to have its own 6to4 gateway, and the encapsulation just happens to be the exact IPv6 packet / IPv4 compatible structure that you use to connect to any other non-gatewayed host.

Re: AWS IPv4 Estate Now Worth $4.5B

#445

Earlier quoted context omitted.

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.

You won't have the "NAT as a firewall" dilemma because there would be no NAT - this whole thought experiment would take place in the 1996 era, before the explosion of NATs. Expecting your /32 gateway to do any firewalling wouldn't be too different from expecting your ISP to do the same for the entire city at the /18 level.

Re: AWS IPv4 Estate Now Worth $4.5B

#446
post #96

Earlier quoted context omitted.

What is your solution?

> What is your solution? Understand very little about the problem space and complain about the best-compromise solution that the people who do know what they're talking about came up with. It's a very comfortable position to be in, I recommend it to everyone.

I mean there's several existing solutions, NAT, ipv4 rationing, ip leasing, coexisting with ipv6.

Things look fine to me, the reality is dual stack, a full ipv6 transition is idyllic and pointless.

I'm certainly not the first ipv6 critic, and you may notice the nuance that I didn't advocate for not using it, I just don't advocate dropping ipv4. Furthermore it doesn't matter if I advocate it or not, like a train ipv4 keeps going, it's only ipv6 that is advocated.

Re: AWS IPv4 Estate Now Worth $4.5B

#447

Earlier quoted context omitted.

It's harder to prove consumer harm with something as abstract as IP addresses, and there's a bunch of other pieces that make this much less unlikely, such as the fact that USBs already become obsolete and need to be replaced, so you're just shifting the replacement cycle.

They don’t need to prove consumer harm to pass laws.

exactly. US anti-trust requires you prove harm to the consumer. In the EU, anti-competitive behavior is enough.

Re: AWS IPv4 Estate Now Worth $4.5B

#448

Earlier quoted context omitted.

Reading, not even trying to understand that list makes my brain explode.

NAT64+DNS64 is the best transition method as it eliminates the need for dual-stack. Clients can be IPv6 only and ideally need a CLAT installed to handle the edge case of IPv4 literals in apps that don't use DNS. The ISP's internal network can be IPv6 only. Only this NAT64 translator needs to speak both IPv6 and IPv4, and only for non-IPv6 traffic.

On hacker news. You're going to find a big contingent of people who are getting things like VPS/colo/dedicated/cloud hosting, only get an IPv6 address on that (or finding that an IPv4 address costs extra) ... and are occasionally finding some customers can't reach their sites without every host having an IPv4 address or paying for something like cloudflare.

So there is a bit of a demand, especially here, for forward compatibility.

Re: AWS IPv4 Estate Now Worth $4.5B

#449

Earlier quoted context omitted.

I can see plenty of situations where colons behaviour might be confusing, let’s start with a http url on a non standard port with credentials embedded, I assume something close to http://01:02@03:04:05:06:07:8000/foo/bar would be a valid url,

Close, it would be more like http://01:02@[03:04:05:06:07:08:09:10]:1112/foo/bar

Great, so now I have to learn a new uri syntax too?

Re: AWS IPv4 Estate Now Worth $4.5B

#450
post #418
post #392

Earlier quoted context omitted.

As a end user, my inbound ports are all closed, and I don't care about scanning. But I don't see why everyone should be able to differentiate traffic from my phone from traffic from my laptop so I'm happy that they use the same public IP to connect outside.

Have you ever heard of TCP/IP stack fingerprinting? It is very likely that someone intercepting your traffic can tell apart your phone and your laptop regardless of the originating IP address. Odds are they can even tell your operating systems.

It's not because someone can say whether I'm at home or not by looking at the lights that putting a plate in front of my home saying whether I'm here or not is a good idea ^^ (sorry for the poor metaphor;) )
Post reply on HN