Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS IPv4 Estate Now Worth $4.5B

toonk.io

Post reply on HN
Print view View original

411–420 of 480 posts

Re: AWS IPv4 Estate Now Worth $4.5B

#411

Post by renewiltord »

dataflow wrote: post #375
welterde wrote: post #205

Earlier quoted context omitted.

The issue is not how can we enable IPv4 C talk to IPv4 S, since that already works. The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. Thus if the server does not have a IPv4-address how does a IPv4-client send packets to it? The inverse situation (IPv6-only client but IPv4-only server) is not really an iss…

> The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. If S is IPv6-only, then either the address is from the IPv4 range, or it's not. If it is, then R can translate between them. If not, then they can't connect. I don't see him suggesting otherwise anywhere. Even ignoring translation possibility, his point h…

It seems like this is the same world as we're currently in. IPv4 hosts can contact each other and can't contact IPv6 hosts. Hosts which are dualstack can be contacted over either stack.

Re: AWS IPv4 Estate Now Worth $4.5B

#413

Post by CodeWriter23 »

flomo wrote: post #130
bradley13 wrote: post #93

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

> Can we go back in time and hit the designers of IPv6 upside the head? Okay we are back in 1992 and are wearing a mullet. 'The Internet' is still a relatively small number of mostly university and government sites, and is barely used for anything important, so a flag day seems pretty feasible.

Damn all those "more than anyone could possibly need" guys

Re: AWS IPv4 Estate Now Worth $4.5B

#414

Post by dataflow »

renewiltord wrote: post #411
dataflow wrote: post #375

Earlier quoted context omitted.

> The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. If S is IPv6-only, then either the address is from the IPv4 range, or it's not. If it is, then R can translate between them. If not, then they can't connect. I don't see him suggesting otherwise anywhere. Even ignoring translation possibility, his point h…

It seems like this is the same world as we're currently in. IPv4 hosts can contact each other and can't contact IPv6 hosts. Hosts which are dualstack can be contacted over either stack.

The problem is the incremental effort (not just software wise, but administrative as well) needed to achieve this outcome. This comment explained it much better than me: https://news.ycombinator.com/item?id=37555424

Re: AWS IPv4 Estate Now Worth $4.5B

#416

Post by ianburrell »

butlerm wrote: post #356
Symbiote wrote: post #326

Earlier quoted context omitted.

What alternative do you suggest for making the IP addresses longer (so more people can connect computers to the Internet) while keeping them equally memorable? The most recent anonymous editor to the IPv6 address article on Wikipedia has address "2602:FBF6:0:0:30C6:7069:6DF0:FD24". An IPv4-like notation of that would be "9730.64502.0.0.12486.28777.28144.64804".

The problem is that adding so many bits to IPv6 addresses, by way of intended integration of the EUI / MAC address in particular is not actually necessary and is a bit of a mistake. As a rule, no one even wants their MAC address propagated across the entire Internet, nor to be registered in DNS either. There are some technical advantages to doing things that way of course, but they are arguably rather outweighed by t…

IPv6 having 128-bit is a huge advantage for transition. NAT64 shoves the 32-bit IPv4 address into the host field.

MAP-T shoves the source and destination IPv4 addresses and ports into IPv6 address. This makes IPv4-IPv6-IPv4 NAT possible. Which means it is possible to run IPv6-only network with IPv4 at on the customer network and edges.

Re: AWS IPv4 Estate Now Worth $4.5B

#417

Post by welterde »

butlerm wrote: post #329
xorcist wrote: post #258

Earlier quoted context omitted.

It's not like people didn't think of that when IPv6 was discussed. It was something like a decade from when the first IPng proposals came to when the proposals which looked like today's IPv6 came. Bernstein was certainly part of that discussion, at the later stages, and the document you link to reflected that. It was just one of many counter proposals that influenced what became IPv6. Some people seem to suggest that…

It is not true that all counterproposals are impossible to deploy, they just have a number of downsides that were either politically or technically impalatable in 1996. For example, the network could have been made administratively compatible (same config files, DNS entries, routing prefixes) for a decade while a variety of internal changes and updates took place as part of the normal upgrade process. I do not mean n…

I don't think that plan is feasible at all.

The incentives for vendors to implement it are just not there, since the customer is not actually going to use the expanded address-space feature at all for at least a decade, so why bother implementing it and break the existing stuff in the process? While with IPv6 you could at least somewhat use it right away or at least implement it on the side, where it won't break the existing stuff. And even if you get the vendor to implement it, chances are they are gonna do it the same way IPv6 got implemented initially: By routing it software, so performance is going to absolutely suck. So the first decade after the proposed flag day performance is going to suck until everyone has upgraded their hardware that can do both in hardware.

Next are the random boxes (firewalls or NAT boxes) that will happily mangle all your option bits in the IPv4 header for no reason. Of course while you haven't used any expanded address space everything will seem fine and might even work fine in the lab, but once your flag day arrives and people are supposed to start using it, you will realize it doesn't actually work, because of all those broken boxes in the wild and fun routing bugs and so forth.

And then you get all the regular bugs that come with making any change that were hidden by no one actually using it. You get all the phases IPv6 went through, but much worse and with a couple decades of delay.

The only way to make things work is by using it. The earlier one gets started the better. Wishing really hard does nothing.

Re: AWS IPv4 Estate Now Worth $4.5B

#418

Post by Thiez »

forty wrote: post #392
dale_glass wrote: post #348

Earlier quoted context omitted.

You can do that with the privacy extensions. Plus on IPv6 you should get enough address space that it makes no sense to run a scan against anyone. On IPv4 or NAT there's just 65535 ports to check. On a /48 with privacy extensions there's 2^80 addresses to go through, which from an external point of view don't remain constant. You can't even ping all of that.

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.

Re: AWS IPv4 Estate Now Worth $4.5B

#419

Post by p1mrx »

supertrope wrote: post #368
ta1243 wrote: post #214

Earlier quoted context omitted.

The fact there are so many options shows the fundamental design problem.

It's iterating over time to fix real problems. No protocol is perfect in the initial RFC.

counterexample: https://datatracker.ietf.org/doc/html/rfc863

Re: AWS IPv4 Estate Now Worth $4.5B

#420

Post by welterde »

dataflow wrote: post #375
welterde wrote: post #205

Earlier quoted context omitted.

The issue is not how can we enable IPv4 C talk to IPv4 S, since that already works. The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. Thus if the server does not have a IPv4-address how does a IPv4-client send packets to it? The inverse situation (IPv6-only client but IPv4-only server) is not really an iss…

> The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. If S is IPv6-only, then either the address is from the IPv4 range, or it's not. If it is, then R can translate between them. If not, then they can't connect. I don't see him suggesting otherwise anywhere. Even ignoring translation possibility, his point h…

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 and less literally, maybe he is actually advocating for the IPv6 we have today? Because there are transition technologies like NAT64, SIIT, 6to4, 6rd, etc. that sort of allow some of the things he suggested? "If the IPv6 configuration isn't automatic, it won't happen." sounds like he is actually advocating SLAAC to me?

Post reply on HN