Live data from Hacker News

AWS to start charging for IPv4 usage, but critical services don't support IPv6

old.reddit.com

221–230 of 245 posts

Re: AWS to start charging for IPv4 usage, but critical services don't support IPv6

#221
post #7

Earlier quoted context omitted.

Is there an alternative, though? Both Python3 and IPv6 both solve problems that would have been at least as painful to do incrementally, IMHO.

> Is there an alternative, though? Certainly some people didn't like the changes of ND vs ARP and such, but once you're changing the address length, you have to alter the data structure on every bit of networking code, and any transition is going to be a slog. IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every netw…

In practice, port number is used as part of address, or, VPN, with tagging, are used. We can make convention that top 4 bits of port number are part of the host address. It will increase number of available addresses by up to 16x.

For example, we have router at 1.2.3.4/192.168.0.254, and 15 hosts behind it, then, by convention, we can access 192.168.0.1 from public internet as 1.2.3.4:32848 (port 32767+1+80), host 192.168.0.3 as 1.2.3.4:32849, and so on.

Re: AWS to start charging for IPv4 usage, but critical services don't support IPv6

#222

Earlier quoted context omitted.

>> The biggest one is people seem to equate NAT = router/firewall. This is absolutely not the case, I dont think anyone equate that, but IPv6 proponents refuse to recognize that decades and decades, especially in home users, and SMB space, NAT was a layer of the security model, often times one of the biggest Right or wrong is irrelevant, that is/was the reality Just tossing IPv6 as a replacement for ipv4 with out fac…

So we're supposed to do things wrong forever because some router vendors are too incompetent to set a firewall as well as NAT? That doesn't seem like a good approach to me.

Right and wrong in this context is subjective there are many things in IPv6 that I find to be wrong convoluted and overly complex

When IPv6 was created they had the opportunity to just make it an expansion of the IPv4 space they chose not to do that and instead they added in a bunch of wish list items that were not needed to accomplish the goal that they were seeking to do which was prevent the exhaustion of IPv4 addresses

Absent address space exhaustion I massively prefer working with IPv4 than I do IPv6

Re: AWS to start charging for IPv4 usage, but critical services don't support IPv6

#223

Do the other cloud providers give you IPv4 endpoints for free? I didn't think that was the case. (ie I thought AWS was just falling into line with the others on charging). As for the "critical services not supporting IPv6" in the post I was quite surprised that it's such a short list of things that don't work - I would have expected more. They've obviously made a ton of progress.

Oracle Cloud does. Linode did, I don't know if they still do. I believe Vultr may. It would take some time for someone to research all cloud providers.

Linode still does. I’m running a business on it (and moving personal stuff over from DigitalOcean). The pricing/performance value proposition on Linode has been fantastic.

Re: AWS to start charging for IPv4 usage, but critical services don't support IPv6

#224

Earlier quoted context omitted.

IPv6 is a privacy nightmare, no privacy technology designed to fix IPv6, fixes it.

How is it any worse than IPv4?

I can’t know for sure what the parent comment was alluding to, but I would assume the idea is that because IPv6 isn’t built around an assumption of NAT, that it’s less private because you don’t have an intermediary router (potentially) concealing traffic origins as a network design feature.

That’s the only thing about IPv6 that I’ve heard of that I think is a reasonable argument regarding a degradation in privacy.

With that said, NAT was a fix for issues that weren’t about privacy, and NAT itself was not designed to give you privacy. It used to be that IPv4 connections were always direct in the same way IPv6 connections were designed to be direct.

In that regard you could make the argument that IPv6 is a regression, but that regression is effectively answering for an architectural shortcoming in IPv4 that we’ve tried hard to fix but that can only go so far.

Edit to add: NAT also doesn’t protect anyone’s privacy anymore than their ISP is willing to protect it anyway, for what it’s worth.

Re: AWS to start charging for IPv4 usage, but critical services don't support IPv6

#225

Earlier quoted context omitted.

Yep, this idea comes up every time because it's actually a good idea.

And every time people explain why the idea is either impossible or describing v6's existing behavior. At what point do these posts become trolling?

I've yet to see a satisfactory explanation of either. It's always basically "you'd still have to change the headers" which misses the point.

Re: AWS to start charging for IPv4 usage, but critical services don't support IPv6

#226

Earlier quoted context omitted.

My v4.1 address would be the same as my v4 address if I was on v4 before. Even if I turn off v4.0, I'm still reachable at the same address on v4.1. This is not the case with v6. That's the problem. Furthermore, the longer addresses would be routed similarly to the 32-bit ones: dst=1.1.1.1.2 would go to the 1.1.1.1/32 router the same exact way dst=1.1.1.1 does. Only difference is what that router does with the packet.

> Even if I turn off v4.0, I'm still reachable at the same address on v4.1. This is not the case with v6. That's the problem. That's not the problem. Being reachable "at the same address on v4.1" (or v6) does not mean that v4 hosts can reach you. In order for v4 hosts to reach you, you have to be doing v4, because v4 hosts will be sending you v4 packets. If you've turned off v4 then that won't work. It'll work if you…

As far as I can tell, nearly every system has an ipv6 stack included, but they are often choosing not to enable it. So ipv6's adoption problem is no longer related to a lack of capabilities on hosts. Do you agree with that?

Let's say every ipv6 stack we have today were instead playing by "ipv4.1"'s rules, meaning same addresses and routing as v4 (and possibly the same packet format as v6). Nobody is taking advantage of longer addresses yet, but the bits are there for later. This also means old DNS entries are still valid, and NATs are still common. What would stop many people from flipping on ipv4.1 mode?

Re: AWS to start charging for IPv4 usage, but critical services don't support IPv6

#227

Hmm... How much is human psychology - Scarce & Expensive is Desirable; Cheap & Plentiful is Low Class - discouraging migration from IPv4 to IPv6?

You wanna bring psychology into it, it seems like v6 abuses the crisis of low address supply to sneak in a bunch of unrelated changes. If the solution were truly just aimed at adding more addresses, it would've looked very different, for instance the existing ipv4 addresses would've been carried over to ipv6. Another thing about humans, addresses like 2001:4860:4860::8888 look awful. You gonna tell me that's an upgra…

Why carry over mistakes from IPv4 when they have an opportunity to fix them? When else are they gonna make those changes?

And how would you propose making larger addresses without making them longer?

Re: AWS to start charging for IPv4 usage, but critical services don't support IPv6

#228

Earlier quoted context omitted.

You wanna bring psychology into it, it seems like v6 abuses the crisis of low address supply to sneak in a bunch of unrelated changes. If the solution were truly just aimed at adding more addresses, it would've looked very different, for instance the existing ipv4 addresses would've been carried over to ipv6. Another thing about humans, addresses like 2001:4860:4860::8888 look awful. You gonna tell me that's an upgra…

Why carry over mistakes from IPv4 when they have an opportunity to fix them? When else are they gonna make those changes? And how would you propose making larger addresses without making them longer?

There isn't a strong enough consensus that these were mistakes, aside from making the address size too small. Maybe removing fragmenting was uncontroversial, but aside from that, ipv6 seems more complicated than ipv4 in many ways. Special kinds of addresses (link-local, v4-mapped, ULA, etc), special ways to write them, and so on.

> And how would you propose making larger addresses without making them longer?

Pre-existing ones don't need to be longer. If my IP before was 1.2.3.4, it stays that way. If a new ISP can't afford /32s for its customers, maybe it hands out /48s like 1.2.3.4.5.6, and if there are ever 282 trillion users, the next one is 1.2.3.4.5.6.7. At home on my LAN, ofc 192.168.1.2 is free and I keep it.

IPv6 addrs are only long because they're spread out.

Re: AWS to start charging for IPv4 usage, but critical services don't support IPv6

#229

Earlier quoted context omitted.

It isn't a big if, it is literally the same connection tracking stack except without the address and port mapping. If you take away the mapping the tracking doesn't go away. Inbound traffic still needs to match to to a session created by outbound traffic.

Yes, and every router has to do it properly by default, which so far they haven't really been. NAT is a lot harder to do wrong, cause the local IPs aren't even addressible.

If they haven't really been, then NAT wouldn't be working either, that's the point I'm making. NAT requires connection tracking to function, because NAT is actually an extra step on top of a basic stateful firewall, and the mapping part isn't the part that provides security, it is the connection tracking part.

Re: AWS to start charging for IPv4 usage, but critical services don't support IPv6

#230
post #60

Earlier quoted context omitted.

the trick is actually to add the extra bytes on the back end. 192.168.8.9.0.1.2.3 old devices get accessed the old way. new devices "know" about the add ons. The new part of the address travels inside "as data" so it gets delivered. as company firewalls and routers switch to new, the whole company needs only one "old" ip. To get the ball rolling, spend some time deploying before it's switched on. All those early adop…

This avoids some core router upgrades, but if you're on a device with a long address then every service you talk to also needs to be upgraded to use the extra bytes. So it still has similar adoption problems. Unless you hide it all with NAT, but if you're doing that then you're losing lots of the benefits of more address space. And the NAT version is something you can already build yourself, but is rarely chosen for…

> Unless you hide it all with NAT, but if you're doing that then you're losing lots of the benefits of more address space.

it enables a graceful transition period

Post reply on HN