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

121–130 of 245 posts

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

#121

Post by hot_gril »

ianlevesque wrote: post #117
redox99 wrote: post #112

Had IPv6 been a superset of IPv4, we would have switched 10 years ago. IPv4 1.2.3.4 becomes IPv6 0.0.0.0.1.2.3.4 Owning IPv6 0.0.0.0.1.2.3.4 means you also own IPv4 1.2.3.4, because addresses that begin with 4 zeroes mean they also own the equivalent IPv4 address. Owning 2.2.2.2.1.2.3.4 means you do not fully own an IPv4 address. In this case you'll have a NAT IPv4 address. If you connect to 1.2.3.4 you use the IPv4…

This comes up every time, but it doesn't make any sense. Routers, software, IT professionals, would've all been just as happy to not support IPv4.1 as they have been to not support IPv6. At this point though the inflection point has already been passed adoption-wise and AWS needs to just do the thing already.

v6 introduces more hurdles. New different kinds of addresses (link-local, etc). No more NAT by default. Existing v4 addresses not accessible over it. In contrast, switching to this "v4.1" would be low-risk. You just support longer addresses, that's it.

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

#122

Post by supriyo-biswas »

redox99 wrote: post #112

Had IPv6 been a superset of IPv4, we would have switched 10 years ago. IPv4 1.2.3.4 becomes IPv6 0.0.0.0.1.2.3.4 Owning IPv6 0.0.0.0.1.2.3.4 means you also own IPv4 1.2.3.4, because addresses that begin with 4 zeroes mean they also own the equivalent IPv4 address. Owning 2.2.2.2.1.2.3.4 means you do not fully own an IPv4 address. In this case you'll have a NAT IPv4 address. If you connect to 1.2.3.4 you use the IPv4…

People keep trotting this out (and there is another conversation about the same topic) but there have been no experiments or evidence to show IPv4 + an additional options header for the additional address parts to have worked better, in terms of compatibility and/or vendor uptake.

A similar issue came up when the internet migrated from class-based to classless IPv4 routing, and in that case, there were experiments that showed most networking gear continued to work and there was little to no adverse effect due to this switch.

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

#123

Post by snuxoll »

hot_gril wrote: post #121
ianlevesque wrote: post #117

Earlier quoted context omitted.

This comes up every time, but it doesn't make any sense. Routers, software, IT professionals, would've all been just as happy to not support IPv4.1 as they have been to not support IPv6. At this point though the inflection point has already been passed adoption-wise and AWS needs to just do the thing already.

v6 introduces more hurdles. New different kinds of addresses (link-local, etc). No more NAT by default. Existing v4 addresses not accessible over it. In contrast, switching to this "v4.1" would be low-risk. You just support longer addresses, that's it.

Supporting longer addresses still means there's no forwards compatibility from v4. Neighbor discovery replacing ARP, link local addresses, etc. are not really the source of headache when it comes to v6 deployments - the legacy environment that v4 created is.

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

#124

Post by wongarsu »

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 is now cheaper than an ipv4 address this is easy to justify if the AWS specific options don't fit your usecase

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

#125

Post by amluto »

throw0101b wrote: post #52
exabrial wrote: post #39

[flagged]

> * "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 hosted providers, I want these services to have different addresses, TYVM. And I want to configure my networking to them without needing to worry about whether all parties actually agree on the addressing scheme.

This is far more important than actually making anything globally routable. If my AWS thingy is 192.168.3.7, I don’t need whatever random third party service I’m using to be able to route to 192.168.3.7 (and I’d probably prefer that it not be able to route there). But I don’t want to worry about the service provider using 192.168.3.7 for another purpose.

I’d also like traceroute to work without having a bunch of intermediate hops where the addresses simply cannot be mapped to their owners without extra side knowledge of the network topology.

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

#126

Post by hot_gril »

devman0 wrote: post #109
hot_gril wrote: post #102

Earlier quoted context omitted.

That's a big "if." > Randomized, temporary IPv6 public addresses are a nice feature, and mostly turned on by default I really do not want this.

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.

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

#127

Post by Dylan16807 »

fsckboy wrote: post #60
MagicMoonlight wrote: post #37

[flagged]

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

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

#128

Post by p1mrx »

fsckboy wrote: post #60
MagicMoonlight wrote: post #37

[flagged]

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…

You're roughly describing 6to4, where 2002:c0a8:0809::123 belongs to 192.168.8.9. Though 6to4 is mostly deprecated, and you generally don't use it with "private" IPv4 addresses, unless you're incrementally deploying IPv6 in an environment where half the switching fabrics are IPv4-only and the other half can do hardware-encap/decap 6to4 but not 6rd.

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

#129

Post by sohex »

Sebguer wrote: post #46
londons_explore wrote: post #40

Earlier quoted context omitted.

Ip addresses have an actual market value now. They cost 50 cents a month to lease. AWS is charging $3.60 per month. Which isn't orders of magnitude off when you consider AWS probably has a poor utilization rate (can only advertise /24's) and profit margins to consider.

IP addresses were intended to be a public good. The fact that AWS has monopolized so many of them, and now that they own a significant fraction of them is deciding to charge for them. It's ridiculous.

So far as I'm aware IP addresses exist out of a functional need, not a moral imperative, but if you have a source with regards to that I'd love to read it. You can hardly call the number of IPv4 addresses that AWS has a monopoly either, iirc they have something like 2% of the IPv4 space? Not charging for them was comparatively strange given that other cloud providers have been charging for them for a good long while. Managing their address space isn't a zero cost endeavor for AWS, so why wouldn't they charge for it? At the least to cover their costs, but given the way the world works these days making a profit isn't weird or unexpected either.

If you're really upset about it you can go through the trouble of registering your own ASN and get on the list to get your own allocation from ARIN. No one is stopping you from doing so.

I think there's an enormous number of things that it's very worth criticizing AWS (and other cloud providers) for, but this really isn't one of them in my book.

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

#130

Post by supriyo-biswas »

GabeIsko wrote: post #120
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/

I'm curious, why can't you use an elastic IP?

This entire thread is about the additional costs imposed on a publicly accessible IP[1].

Granted, there are other (but similarly expensive) workarounds such as NAT gateways[2] for outbound connectivity or the cheaper NAT instance method which AWS doesn't support any more, but there are alternatives[3]. However, for use cases requiring inbound connectivity such as setting up websites on EC2 instances, or using an ELB which need internet access, you need an IPv4 address and these charges definitely rack up.

[1] https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...

[2] https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gat...

[3] https://fck-nat.dev

Post reply on HN