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

161–170 of 245 posts

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

#161

Post by throw555chip »

throw0101b wrote: post #25
JoshTriplett wrote: post #20

Earlier quoted context omitted.

IPv6 provided some features people needed (larger addresses), made some changes born from experience (removing IP-level header checksums in favor of packet checksums like those in UDP and TCP, removing fragmentation), and then bundled in a pile of mandatory added complexity (DAD, SLAAC and router advertisements rather than DHCP, initially mandatory IPsec). If IPv6 had left out the mandatory added complexity, and just…

> […] 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.

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

#162

Post by icehawk »

hot_gril wrote: post #126
devman0 wrote: post #109

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.

Its not harder to do wrong, its just less noticeable when done wrong, it's been a security consideration since NAT was created, and a persistent issue since then:

https://datatracker.ietf.org/doc/html/rfc2993#page-22

https://threatpost.com/remote-attackers-internal-network-dev... https://www.anvilsecure.com/blog/dhcp-games-with-smart-route...

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

#163

Post by madsr »

wongarsu wrote: post #124
radarsat1 wrote: post #32

To be fair I have a bunch of instances with public IP addresses just so I can ssh into them easily. This situation made me look into how I'd get into these instances otherwise and indeed you can set up an appropriate endpoint and then run "aws ec2 instance-connect" to make a tunnel that gets you an ssh connection without needing the public IP, so just like that my needs for public IPs actually goes down pretty drasti…

The traditional method to achieve this is a ssh bastion. You have one tiny server running that has a publicly reachable IP, and can also reach the other servers (usually via the private network). You ssh into the bastion, then ssh from there into your actual server (or use port forwarding to make an ssh connection via the bastion, which some tooling supports out-of-the-box). Considering the cheapest ec2 instance type…

Bastions are a good option. sshd supports jumping through them by default using the -J flag (jump) or automatically by adding the 'ProxyJump' statement to your .ssh/config.

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

#164

Post by bigstrat2003 »

phpisthebest wrote: post #70
jjjjmoney wrote: post #48

Earlier quoted context omitted.

> ok, but why? Because NAT breaks a lot of services. > Is that going to change with ipv6? Yes. You no longer need NAT, so port negotiation is much easier (even when inbound is blocked) > Are you _really_ just going to allow random traffic into your network? Common misconception! Even without NAT, the router can have port/traffic policies. There's just no address translation happening. There's a lot of good stuff abou…

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

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

#165

Post by ars »

wongarsu wrote: post #124
radarsat1 wrote: post #32

To be fair I have a bunch of instances with public IP addresses just so I can ssh into them easily. This situation made me look into how I'd get into these instances otherwise and indeed you can set up an appropriate endpoint and then run "aws ec2 instance-connect" to make a tunnel that gets you an ssh connection without needing the public IP, so just like that my needs for public IPs actually goes down pretty drasti…

The traditional method to achieve this is a ssh bastion. You have one tiny server running that has a publicly reachable IP, and can also reach the other servers (usually via the private network). You ssh into the bastion, then ssh from there into your actual server (or use port forwarding to make an ssh connection via the bastion, which some tooling supports out-of-the-box). Considering the cheapest ec2 instance type…

Newer versions of ssh have the -J option which lets you enter the bastion host and it does everything else automatically.

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

#166

Post by inopinatus »

supriyo-biswas wrote: post #105
ianburrell wrote: post #101

I'm not sure what the AWS services not supporting IPv6 has to do with charging for public IPv4 usage. Private IPv4 is still free so can access services over endpoints. NAT gateways cost the same and can access services over public IPv4 network. AWS also added IPv6 NAT64 gateway so it should be possible to run IPv6-only internally and still access AWS services and the rest of the Internet.

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 results in S3. Caveat programmer: only suitable if the task is not latency sensitive.

DynamoDB/Lambda are not everyone's cup of tea, but it's nice to have options.

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

#167

Post by bigstrat2003 »

hot_gril wrote: post #146
hackmiester wrote: post #139

Earlier quoted context omitted.

The lack of NAT represents the removal of an issue. The fact that you already understand NAT does not reduce the actual, real complexity that it is introducing.

NAT is a more desirable form of security than a firewall for most users, despite it not being intended for that purpose. It should be the default, and if you don't want NAT, go ahead and don't use it.

> NAT is a more desirable form of security than a firewall for most users...

I don't agree with this. First, most users don't know or care about security. So neither is more desirable for them. But also, on its merits NAT isn't more desirable. It provides zero security that is not provided by a simple default deny inbound rule on a firewall. And on top of that, it introduces additional complexity that even a non-technical user has to contend with sometimes (port forwarding).

NAT is not and never has been a security mechanism. We need to stop trying to shoehorn it in to a role it isn't meant for.

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

#168

Post by throw0101b »

amluto wrote: post #125
throw0101b wrote: post #52

Earlier quoted context omitted.

> * "OMG Every device needs a publicly addressable IP!!!" > ok, but why? So we can get rid of STUN/ICE/ etc and make peer-to-peer easier. All you're left with is hole punching through your SPI firewall (no worse than today). > Are you _really_ just going to allow random traffic into your network? I don't know why this misconception is so wide spread: globally addressable ≠ globally reachable . Firewalls still exist w…

> > ok, but why? > So we can get rid of STUN/ICE/etc and make peer-to-peer easier. All you're left with is hole punching through your SPI firewall (no worse than today). There’s (IMO) a much better reason: so your endpoints can have globally unique addresses. If I have a service in Google Cloud and a service in AWS and an on-prem service and a customer service and ten different upstream services from ten different ho…

> There’s (IMO) a much better reason: so your endpoints can have globally unique addresses.

Complications with address space collisions (esp. M&A) was one of the reasons given in this Wells Fargo presentation from 2014:

* https://www.youtube.com/watch?v=EzTWjNUb4H4

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

#169

Post by pests »

wenbin wrote: post #103

We [1] just went through a process to remove public ipv4 IPs for some of our internal facing EC2 instances. Just in case some people are on the same boat. Here's a simple process [2] to remove public ipv4 IPs from existing EC2 instances (no need to shutdown / reboot) - 1) Create a new elastic ip with autoassigned ipv4 IP - https://us-west-1.console.aws.amazon.com/ec2/home?region=us-... : 2) Associate this new elastic…

Note to others: the network interface created in step 3 has to stay and cannot be deleted. If deleted the ip4 will come back.

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

#170

Post by saltminer »

cesarb wrote: post #142
hot_gril wrote: post #98

Earlier quoted context omitted.

If that's the problem, then the solution would've been just adding more address space to ipv4, preserving all existing addresses and pretty much everything else about it. 1.1.1.1/32 is still 1.1.1.1/32, and new ISPs can take blocks like 72.33.22.11.33/40 once enough routers are updated to support them. This could've even used the exact ipv6 packet structure, making it quite similar to v6 under the hood but more like…

> If that's the problem, then the solution would've been just adding more address space to ipv4, preserving all existing addresses and pretty much everything else about it. That's not possible. IPv4 addresses are 32-bit numbers. Once you change that, you're no longer "preserving existing addresses". > once enough routers are updated to support them. That's actually "once all routers and end devices are updated to sup…

> That's actually "once all routers and end devices are updated to support them". As the classic spamsolutions.txt says, "requires immediate total cooperation from everybody at once".

This point cannot be emphasized enough. To quote Hyrum's Law [0]:

> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

And for networking this means that, even if the NRO decreed that all reserved/testing IPv4 blocks [1] would be publicly routable and turned over to the RIRs for allocation, those blocks would be effectively unusable. It doesn't matter how many RFCs you produce saying "you must assume these addresses will be someday used", networking hardware and software has ossified around specific expectations pertaining to what addresses are valid and invalid, what protocols are acceptable, etc.

A great example of this is TLS 1.3: due to protocol ossification, the spec had to be rewritten to be more similar to TLS 1.2 because network middleboxes kept assuming it was a threat and blocking the connections [2]. This is also the reason SCTP has yet to gain widespread adoption, and why any new layer 4 protocol is likely doomed to fail: networking hardware hates anything that deviates from the acceptable traffic patterns which have been hard-coded in, RFCs be damned.

Imagine if previously unused IPv4 blocks started getting allocated. You'd be cut off from most of the internet, and most of the internet would be cut off from you. It wouldn't be enough, of course - even if all 2^32 addresses were publicly routable, that's still not even enough for 1 IP per person, you'd still have to rely on NAT, and all the problems it causes. (This is also why I think suggestions like "organizations like Apple who have a /8 but barely use it should just give up those extra IPv4s" are misguided and really understate of the scale of the problem - it's just putting a band-aid on an open fracture that cut your femoral artery.)

[0]: https://www.hyrumslaw.com/

[1]: https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4

[2]: https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet...

Post reply on HN