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

191–200 of 245 posts

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

#191

Post by hot_gril »

snuxoll wrote: post #188
hot_gril wrote: post #177

Earlier quoted context omitted.

It's not shoehorned, though. Corporate and home users find it convenient. It's very hard to screw up, unlike v6 firewalls which often have bad defaults or possibly don't work as intended. Especially when one of the other goals of ipv6 is to enable p2p applications, which might lead to permissive defaults. My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to addr…

> My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. Only because your router also has a properly configured stateful firewall for ipv4 as part of its NAT implementation. I have a Mikrotik CCR2004 at home, I can enable SNAT without appropriate firewall rules and have any other customer of…

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

Yes, that's the exact dealbreaker for me and many corp environments.

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

#192

Post by [deleted] »

redox99 wrote: post #181
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.

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…

[deleted]

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

#193

Post by hot_gril »

redox99 wrote: post #181
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.

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.

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

#194

Post by snuxoll »

hot_gril wrote: post #133
snuxoll wrote: post #123

Earlier quoted context omitted.

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.

v4.1 host is still addressable from v4 host as long as its address is 32-bit. So they don't start leasing out the longer ones until v4.1 adoption is good enough. In the meantime, you slap in v4.1 hardware without having to even think about it. You can also make compromises with NAT, like handing out 40-bit addresses that are auto-translated to/from 32-bit with 8 bits going into the port.

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 long it's taken the world to adopt IPv6. The fact that they have to do anything at all is, and there's no solution around that.

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

#195

Post by fanf2 »

throw0101b wrote: post #172
JoshTriplett wrote: post #93

Earlier quoted context omitted.

> plug in and the router sends the information and you're done. If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server. (With added bonus "this could happen asynchronously at any time and you never reliably know when your network is…

> If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server. I've had to fight with ip-helper issues and DHCP scopes enough times to not wish to have to deal with it if possible. I have to configure the router (or the VLAN on a Layer 3…

You also need to turn off DAD because if the computer comes up without a link, DAD will fail with a timeout and ifup will leave IPv6 unconfigured.

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

#196

Post by hot_gril »

snuxoll wrote: post #194
hot_gril wrote: post #133

Earlier quoted context omitted.

v4.1 host is still addressable from v4 host as long as its address is 32-bit. So they don't start leasing out the longer ones until v4.1 adoption is good enough. In the meantime, you slap in v4.1 hardware without having to even think about it. You can also make compromises with NAT, like handing out 40-bit addresses that are auto-translated to/from 32-bit with 8 bits going into the port.

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.

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

#197

Post by radarsat1 »

lightlyused wrote: post #100
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…

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 image 'amazon/aws-cli:latest' locally
  latest: Pulling from amazon/aws-cli
  6ebddf7084e9: Pull complete 
  eb7d160dbc3b: Pull complete 
  af71d24e41d0: Pull complete 
  cf26adf9ea98: Pull complete 
  2491adb1df28: Pull complete 
  Digest: sha256:a8c8edb4641672d9ef61873594aa02d1c493341ca30f96e257fdc4d3da17ef9c
  Status: Downloaded newer image for amazon/aws-cli:latest
  
  A newer release of "Amazon Linux" is available.
And now I am logged into the machine. You can clearly see that it downloaded an AWS docker image. Exit from ssh, back to local terminal, and now there is an image on my machine:

  $ docker images | grep aws-cli
amazon/aws-cli latest 817d1061df76 3 hours ago 384MB

So I don't know if I agree that aws ec2-instance-connect doesn't use docker. And also, I don't necessarily have a problem that it does, it just surprised me a bit.

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

#198

Post by snuxoll »

hot_gril wrote: post #191
snuxoll wrote: post #188

Earlier quoted context omitted.

> My home router has one public IP and many private IPs. No matter how crappy my router is, it's impossible to address private IPs from the outside except on the random mapped ports. Only because your router also has a properly configured stateful firewall for ipv4 as part of its NAT implementation. I have a Mikrotik CCR2004 at home, I can enable SNAT without appropriate firewall rules and have any other customer of…

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=input comment="defconf: drop invalid" connection-state=invalid
    add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
    add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
    add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
    add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
    add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
    add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
    add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
    add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
    add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
    /ip firewall nat
    add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
You would have to have a system on the same subnet as the public interface of my router to try and take advantage of these rules not being in place (because of the nature of how IP forwarding works), but without them it would absolutely forward them because the route table just looks like this

        DST-ADDRESS       GATEWAY                DISTANCE
    DAd 0.0.0.0/0         1.1.1.1                       1
    DAc 1.1.1.0/24        wan1                          0
    DAc 192.168.0.0/24    lan1                          0
Note, it's just one route table - with IP forwarding enabled the only thing stopping anything coming in the WAN interface from being capable of forwarding to the LAN interface is the firewall rule.

> Yes, that's the exact dealbreaker for me and many corp environments.

My point remains, NAT is not a security measure - any corporate environment who thinks they are protected merely because they have NAT enabled is fooling themselves. The exact same set of firewall rules I need to properly secure IPv4 traffic are the same ones I need for IPv6 traffic; the only reason I haven't bothered to copy/paste them is because my ISP in 2023 still does not hand me an IPv6 allocation.

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

#199

Post by snuxoll »

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.

> 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 - if you do anything to change the structure of the packet header the same problem happens, no matter what.

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

#200

Post by throw0101b »

fanf2 wrote: post #195
throw0101b wrote: post #172

Earlier quoted context omitted.

> If you want the network to come up in a timely fashion, the new system needs to poke the network to get information proactively sent to it as soon as possible, at which point you have about the same level of complexity as poking a DHCP server. I've had to fight with ip-helper issues and DHCP scopes enough times to not wish to have to deal with it if possible. I have to configure the router (or the VLAN on a Layer 3…

You also need to turn off DAD because if the computer comes up without a link, DAD will fail with a timeout and ifup will leave IPv6 unconfigured.

So:

    dad-attempts 0
* https://manpages.debian.org/stable/ifupdown/interfaces.5.en....
Post reply on HN