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

201–210 of 245 posts

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

#201

Post by js2 »

radarsat1 wrote: post #197
lightlyused wrote: post #100

Earlier quoted context omitted.

aws ec2-instance-connect doesn't use docker, it just sets up a short lived ssh key in the instance metadata that you can use to connect. You can connect either via a public ipv4, ipv6, or a vpc private endpoint.

I don't really know any details, but all I can tell you is that this is the output of running it in a fresh environment (masked out the instance details and snipped some output..): $ docker rmi amazon/aws-cli $ cd /tmp $ python3 -m venv venv $ . venv/bin/activate $ pip install awscliv2 $ ssh -i mykey.pem ec2-user@i-masked -o ProxyCommand='awsv2 ec2-instance-connect open-tunnel --instance-id i-masked' Unable to find i…

You're confusing `awscliv2`[1], a third-party Python wrapper around AWS CLI v2[2], with instance connect. From its package page:

- This is not an official AWS CLI v2 application

- By default this app uses amazon/aws-cli Docker image

The only official macOS distribution of AWS CLI v2 is via a macOS installer package:

https://docs.aws.amazon.com/cli/latest/userguide/getting-sta...

It's also available in Homebrew[3] but the packaging is maintained by a third-party, not Amazon.

[1] https://pypi.org/project/awscliv2/

[2] https://awscli.amazonaws.com/v2/documentation/api/latest/ind...

[3] https://formulae.brew.sh/formula/awscli

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

#202

Post by hot_gril »

snuxoll wrote: post #199
hot_gril wrote: post #196

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.

> 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 could later divide up their /32s and hand out, say, /88s to customers. Address crunch would've been already averted.

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

#203

Post by radarsat1 »

js2 wrote: post #201
radarsat1 wrote: post #197

Earlier quoted context omitted.

I don't really know any details, but all I can tell you is that this is the output of running it in a fresh environment (masked out the instance details and snipped some output..): $ docker rmi amazon/aws-cli $ cd /tmp $ python3 -m venv venv $ . venv/bin/activate $ pip install awscliv2 $ ssh -i mykey.pem ec2-user@i-masked -o ProxyCommand='awsv2 ec2-instance-connect open-tunnel --instance-id i-masked' Unable to find i…

You're confusing `awscliv2`[1], a third-party Python wrapper around AWS CLI v2[2], with instance connect. From its package page: - This is not an official AWS CLI v2 application - By default this app uses amazon/aws-cli Docker image The only official macOS distribution of AWS CLI v2 is via a macOS installer package: https://docs.aws.amazon.com/cli/latest/userguide/getting-sta... It's also available in Homebrew[3] but…

Oh I see. I installed awscliv2 after discovering that awscli did not have the ec2-instance-connect command, so I could not follow the documentation and went searching to see if there was an updated package and discovered that one. So I guess you are not supposed to install it using pip anymore. Good to know.

Update: and now I've read through the github issue, oh my I've missed quite some drama.

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

#204

Post by sohex »

throw555chip wrote: post #152
sohex wrote: post #129

Earlier quoted context omitted.

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

> 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. OK https://www.theverge.com/2017/12/19/16792306/fcc-net-neutral... "For Licklider, this wasn’t just a new technology, but a new way for human beings to exist in the world."

Are we talking about IPv4 addresses or are we talking about the internet as a whole? Because that quote seems to be about the latter and I was referring to the former above. I read the Licklider paper that they link and it's much more on the abstract side rather than discussing actual implementation details.

Licklider and Taylor did have some very interesting predictions about how the internet would shape up though. Probably my favorite quote from the article:

"Unemployment would disappear from the face of the earth forever, for consider the magnitude of the task of adapting the network’s software to all the new generations of computer, coming closer and closer upon the heels of their predecessors until the entire population of the world is caught up in an infinite crescendo of on-line interactive debugging."

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

#205

Post by hot_gril »

snuxoll wrote: post #198
hot_gril wrote: post #191

Earlier quoted context omitted.

NAT is not a firewall. It's not actively blocking anything, rather it's actively forwarding things. If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. I mean sure a NAT could intentionally pick my local IP as the lucky winner of every inbound packet, but how does that happen on accident. > IPv6 just exposes such poor configurations mo…

> If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. Yeah, it does in many (most) cases. That's precisely why my firewall rules on my own router look like this: /ip firewall filter add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked add action=drop chain=…

> You would have to have a system on the same subnet as the public interface of my router

Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that.

Yes, you shouldn't rely on NAT alone, rather the router should have a firewall. Usually it does, but not always. When that fails, at least it's still pretty hard to exploit. How often does this kind of attack occur?

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

#206

Post by js2 »

radarsat1 wrote: post #203
js2 wrote: post #201

Earlier quoted context omitted.

You're confusing `awscliv2`[1], a third-party Python wrapper around AWS CLI v2[2], with instance connect. From its package page: - This is not an official AWS CLI v2 application - By default this app uses amazon/aws-cli Docker image The only official macOS distribution of AWS CLI v2 is via a macOS installer package: https://docs.aws.amazon.com/cli/latest/userguide/getting-sta... It's also available in Homebrew[3] but…

Oh I see. I installed awscliv2 after discovering that awscli did not have the ec2-instance-connect command, so I could not follow the documentation and went searching to see if there was an updated package and discovered that one. So I guess you are not supposed to install it using pip anymore. Good to know. Update: and now I've read through the github issue, oh my I've missed quite some drama.

I agree it's confusing and I think Amazon's reasons for dropping PyPI support are pretty lame:

https://github.com/aws/aws-cli/issues/4947#issuecomment-5860...

They also have't provided a reason for why they don't distribute via Homebrew:

https://github.com/aws/aws-cli/issues/727

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

#207

Post by hot_gril »

noirscape wrote: post #61
ryandvm wrote: post #3

IPv6 and Python3 are case studies in how not to roll out a new version unless you're cool with multi-decade upgrade windows.

At least with Python3, there was eventually Python 2.7 to permit a compatibility layer to move over. It took ages, but there was at least a "best effort" to help people write code that could be easily moved between 2 and 3. (In spite of apparent behavior from the Python developers at the time). IPv6's hard break with IPv4 means that the switchover likely won't happen anytime soon.

IMO they should've just conceded and added a `print` syntax to Py3 similar to Py2. Stupid as it sounds, that was often the only reason someone's script was Py2-only. That and the integer division should've stayed the same.

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

#208

Post by hot_gril »

bell-cot wrote: post #113

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 upgrade over 8.8.8.8? And 192.168.1.2 becomes fe80::1c03:b6d1:9222:3a02. Why can't I keep 192.168.1.2?

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

#209

Post by GabeIsko »

supriyo-biswas wrote: post #130
GabeIsko wrote: post #120

Earlier quoted context omitted.

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…

Ah, I think i had the connectivity backwards. I thought the complaint was about hosts connecting to these services, not inbound connections to hosts.

Ultimately, they will probably want people to solve it with service endpoints, and give preferred pricing on that. But I kind of get why that is a bit wigged out. Because it locks more architecture into them as a vendor. I'm not really sure putting a public ip is a good solution to this, but it is kind of scary because suddenly we are deciding infrastructure decisions more based on how they are being priced. Needs regulation.

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

#210

Post by snuxoll »

hot_gril wrote: post #205
snuxoll wrote: post #198

Earlier quoted context omitted.

> If NAT drops the ball in various ways, the router still doesn't know to send dst=71.177.17.171 to my PC on 192.168.1.2 vs another one. Yeah, it does in many (most) cases. That's precisely why my firewall rules on my own router look like this: /ip firewall filter add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked add action=drop chain=…

> You would have to have a system on the same subnet as the public interface of my router Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that. Yes, you shouldn't rely on NAT alone, rather the router…

> Making sure I understand, you mean an attacker sends dst=192.168.1.2 directly to your router without any extra hops, which the router forwards to your PC. I don't know if that's what happens in practice (there's no legit reason to do it), but I can see a router doing that.

Yes, you understand the problem correctly. The fact that there's no legitimate reason to do it is precisely why routers have a default set of firewall rules to prevent it. Hell, as long as you control enough of the network to be able to route such a packet to the WAN interface of your router it doesn't even have to be on the same network segment - so compromise within your ISP's network would open you up to attack if you just assumed NAT alone without a proper stateful firewall would save you.

> How often does this kind of attack occur?

Due to needing to be on the same layer 2 segment or having control elsewhere of the network this would very much be a targeted attack. But one any enterprise should care about, and why the assumption that NAT alone is what protects you is dangerous. NAT just does source/destination (ip, port) rewriting, that's it.

Post reply on HN