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

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

old.reddit.com

Post reply on HN
Print view View original

211–220 of 245 posts

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

#211

Post by lxgr »

jjjjmoney wrote: post #87
phpisthebest wrote: post #70

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…

> Just tossing IPv6 as a replacement for ipv4 with out factoring that in while simply screaming into the void "NAT IS NOT A FIREWALL" will be of little comfort to the elderly retiree that has their home computer ransomwared, or the small business that is put under due to a cyber attack because the ipv6 address was strait on the public internet This is definitely what I'm seeing. IPv4 is really engrained in us - I act…

> The major downside I see right now is that "addresses are harder to memorize," but there are solutions to that as well.

Definitely. That DNS thing sounds promising!

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

#212

Post by snuxoll »

hot_gril wrote: post #202
snuxoll wrote: post #199

Earlier quoted context omitted.

> 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. IPv4 packets have 32-bit address fields in the packet header, 1.1.1.1/32 still needs to understand IPv4.1 packets or it's going to think you're sending it corrupt garbage. Again, nothing changes…

Yes, the packet header changes. Basically all routers have supported v6 packets for a while, which was a large effort, but evidently it was possible. And yet, we've not collectively adopted v6. We are stuck with dual stacks. If the same support was added except with the /32s preserved, everyone could've switched to v4.1 with basically no change to the routing, DNS, NAT, etc. Not a big jump like going to v6. Then ISPs…

> with basically no change to the routing, DNS, NAT, etc.

Except you're wrong on all of the above.

We'd still need a completely different "v4.1" routing layer, because a /32 could never be a subnet while also being a distinct endpoint, so we'd have to treat any routes smaller than a /33 as being the old IPv4 world while a /33 and bigger would be v4.1. So we still end up with the exact same split, except now our address space is an even bigger fucking mess instead of the clear break v6 is giving us to make a more hierarchical network (eventually getting rid of the ludicrous routing table bloat we currently have, though we really need to come up with a better solution for multi-WAN failover in small networks to avoid everyone and their dog needing an ASN and BGP session to have a HA setup).

DNS would still need changes, because the struct for an A record still contains a 32-bit address.

Nothing stopped us from using NAT with IPv6, but it sucks and broke end to end connectivity so while we already had to break the world to make the switch why not deal away with the ugly hack while we were at it.

There is no world in which any successor to IPv4 did not have a long transition time without government mandates, and that's basically what it is taking to get ISP's and cloud providers to adapt it (the whole reason AWS, Azure, GCP, et. al. are slowly getting their shit together is the US government is mandated to go single stack).

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

#213

Post by hot_gril »

snuxoll wrote: post #212
hot_gril wrote: post #202

Earlier quoted context omitted.

Yes, the packet header changes. Basically all routers have supported v6 packets for a while, which was a large effort, but evidently it was possible. And yet, we've not collectively adopted v6. We are stuck with dual stacks. If the same support was added except with the /32s preserved, everyone could've switched to v4.1 with basically no change to the routing, DNS, NAT, etc. Not a big jump like going to v6. Then ISPs…

> with basically no change to the routing, DNS, NAT, etc. Except you're wrong on all of the above. We'd still need a completely different "v4.1" routing layer, because a /32 could never be a subnet while also being a distinct endpoint, so we'd have to treat any routes smaller than a /33 as being the old IPv4 world while a /33 and bigger would be v4.1. So we still end up with the exact same split, except now our addre…

They need to retrofit those things to support longer addresses, but I mean the existing data and rules don't change. The DNS records and IP routes stay the same. And no, you don't introduce special v4 vs v4.1 routing. For this phase, everyone is still using /32s.

Then once basically everything is speaking v4.1 and ok with longer addrs, it's trivial to split up /32 blocks as desired. And yes, NAT stays for most people. That's fine, you'd still be free to disable it and give your devices public IPs if you want.

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

#215

Post by Dagger2 »

hot_gril wrote: post #193
redox99 wrote: post #181

Earlier quoted context omitted.

Not at all. This would be much easier to migrate and support. Nowadays you have two entire separate stacks, each with their own firewall rules. That's why the first thing I do is outright disable IPv6 because of the potential security issues due to misconfiguration. The hardware and operating systems have supported IPv6 for a very long time. The problem is that it's a pain in the ass to maintain 2 stacks simultaneous…

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?

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

#216

Post by Dagger2 »

devit wrote: post #186
paulgb wrote: 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.

A much simpler and compatible solution would be to assign a single IPv4 address per AS and then use IP options to pass additional address bits to identify the specific host within the AS.

That wouldn't be simple or compatible, but also... v6 basically already has what you're suggesting here, except forget every AS: every single v4 address already has a /48 of v6 space tunnelled to it.

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

#217

Post by Dagger2 »

throw555chip wrote: post #161
throw0101b wrote: post #25

Earlier quoted context omitted.

> […] and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec). SLAAC and RA reduce complexity as you no longer need 'extra' infrastructure (DHCP) to get going: plug in and the router sends the information and you're done. You also get rid of the complexity of STUN/ICE/ etc as you no longer need NAT, so you just need hole punching for…

Those are the very things that makes IPv6 anti-privacy. We lose all control at the router level. Users are served up like lambs to the privacy slaughter.

Uh... what.

You don't lose control at the router level. v6 isn't anti-privacy and there's no privacy slaughter in it. RAs have no privacy impact and SLAAC makes no meaningful difference.

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

#218

Post by Dagger2 »

hot_gril wrote: post #196
snuxoll wrote: post #194

Earlier quoted context omitted.

And a IPv6 host is still addressable from an IPv4 host as long as it has an IPv4 address. You've done absolutely nothing to spur adoption - because the mere fact that you extended the address space and required infrastructure all across the globe to be replaced and reconfigured to support it causes the exact same issues. Again, neighbor discovery, SLAAC, link-local addressing, none of it has anything to do with how l…

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 leave v4 on... but then you're just doing dual stack, and v6 can do that too.

The problem here is that you haven't realized that what you're describing is no different to v6's approach, just phrased differently.

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

#219

Post by Dagger2 »

gray_-_wolf wrote: post #184
oarsinsync wrote: post #36

Earlier quoted context omitted.

Are there recommendations that result in IPv6 looking like something more than just IPv4 with bigger addresses? Yes. Is there anything stopping you from effectively running IPv6 networks the same way as you run IPv4 networks, but with larger address pools? No. You can do NAT66, you can do DHCPv6, you can run every network as a /120 (IPv6 equivalent of a /24 - 256 addresses) if you want to as well. You can even (outsi…

Sure, I don't have to, but everything in the stack assumes I would run it in the recommended way. I gave up trying to setup my LAN to support IPv6 after I wasted more than 2 hours on convincing my router, and devices behind it, to somehow work with the /128 address I got from my ISP. Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it? No, there is not, everyt…

That's because there are good reasons for running it in the recommended way. If you're going to go out of your way to run it in bad, unpopular ways instead then it's on you to get devices that support what you're trying to do. (For example, squid on Linux would do it just fine, whereas some random consumer WiFi/switch/router combo thing is probably not going to go far outside of its basic functionality.)

Instead of giving up, I'd suggest doing it the normal way -- do DHCPv6-PD to get a routed prefix, use that on the LAN and route to the Internet. On most v6-capable routers that's the default and will happen automatically, and it would be hard to make it easier to roll out than that.

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

#220

Post by supriyo-biswas »

inopinatus wrote: post #166
supriyo-biswas wrote: post #105

Earlier quoted context omitted.

This would be acceptable if this internal route was already configured for free. However, it appears VPC endpoints have their own pricing[1], at which point one must carefully consider whether paying up for the IPv4 address is the better option. [1] https://aws.amazon.com/privatelink/pricing/

Interestingly, S3 and DynamoDB access from privately addressed IPv4 VPCs is free, since it's implemented as routes not endpoints, and although rather constraining you can definitely build things with that. Case in point, I had some internal instances that very occasionally want to pull files from a partner's endpoint. Previous solution, NAT gateway. New solution, DynamoDB request table streamed to AWS Lambda and resu…

> S3 and DynamoDB access from privately addressed IPv4 VPCs is free, since it's implemented as routes not endpoints

TIL. Thanks!

Post reply on HN