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

171–180 of 245 posts

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

#171

Post by pixl97 »

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.

>IP addresses were intended to be a public good.

Then it was a pretty poor idea to have less IPs than humans on the planet.

We have IPv6 which, at least for the time being can give every individual a few zillion IPs. Providers like this just need to get them rolled out.

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

#172

Post by throw0101b »

JoshTriplett wrote: post #93
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…

> 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 switch) anyway, so a few extra lines for /64 scopes that are sent out via RAs on the same device I have to touch anyway is easier.

> The reaction I have every time I interact with IPv6 is that it seems incredibly hard to make a system just use the configuration you tell it to use and never ever listen to any configuration from the network.

On Debian with interfaces(5):

    auto eth0
    iface eth0 inet6 static
        address 2001:db8:aaa:bbbb:cccc::dead:beef
        netmask 64
        gateway 2001:db8:aaa:bbbb:cccc::1
        accept_ra 0
For Netplan-based stuff, this looks similar:

* https://github.com/canonical/netplan/blob/main/examples/dire...

I recently had to switch ISPs to one that doesn't do IPv6 for FTTH (but their smart offerings are (AFAICT) IPv6-only), but my previous IPv6 did, and activating it for my home network was a couple clicks on my Asus router: all my devices (including a networked printer) picked it up without issue.

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

#173

Post by throw0101b »

nimish wrote: post #137
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…

The complexity is already paid for since you aren't going to be able, or even want to, wholly rip and replace IPv4 since it gains very little and risks a lot. IPv6 would have been great if it didn't have to work in a brownfield environment. Unfortunately, nobody is going to change because it's conceptually purer to not have those ancillary protocols. This is what the creators of v6 failed to consider: IPv4 was entren…

> The complexity is already paid for since you aren't going to be able, or even want to, wholly rip and replace IPv4 since it gains very little and risks a lot.

You should tell that to Microsoft:

* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...

Veronika McKillop is now President of the UK IPv6 Council:

* https://www.youtube.com/@ukipv6council468/videos

* https://fr.linkedin.com/in/veronika-mckillop-ipv6

> It's classic second-system effect and design by people without production experience or skin in the game.

Begin with "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" for part of the discussion from back in the day (1993):

* https://datatracker.ietf.org/doc/html/rfc1347

The author of that document attended the first IETF meeting in 1986; interview:

> He’s now a Distinguished Engineer at Juniper Networks, author of 14 RFCs, and chair of the MPLS Working Group at IETF.

* https://www.internetsociety.org/blog/2016/02/interview-ross-...

* https://www.linkedin.com/in/ross-callon-b8383695

He co-edited the MPLS architectural document:

* https://datatracker.ietf.org/doc/html/rfc3031

But sure: "without production experience or skin in the game".

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

#174

Post by hot_gril »

throw0101b wrote: post #154
hot_gril wrote: post #145

Earlier quoted context omitted.

Building it is the same amount of work as building ipv6 support. Adopting it is not the same work as adopting v6. We already have ubiquitous v6 hardware/software support, but it's a whole 'nother thing to actually use it. 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready. By the way, the WWW has gone through transitions like adopting HTTPS and banning old versions of TL…

> 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready. When who is ready? Different people/organizations will be ready at different times. Some people will not be able to get IPv4 addresses so will be 'stuck' with being IPv4.1-only. Given the finite IPv4 addresses, some will move the IPv4 addresses to revenue-generating areas and will go IPv4.1-only internally—which is wh…

Switch to >32-bit when enough routers/hosts support it, i.e. they can parse the new packet format. We've already accomplished that with v6 long ago.

In the meantime, ISPs that cannot afford enough 32-bit addresses for their customers can hand out 40-bit ones and perform a NAT-like translation. Same as what they're doing now with cgnat, except there's an exit strategy.

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

#175

Post by fragmede »

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…

just a quick aside, but the ipv4 address is mapped inside the ipv6 address space. 192.0.2.1 is represented in IPv6 as ::ffff:192.0.2.1. This is known as IPv4-mapped IPv6 addresses.

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

#176

Post by throw0101b »

hot_gril wrote: post #174
throw0101b wrote: post #154

Earlier quoted context omitted.

> 1. Add v4.1 support, but keep using 32-bit addresses. 2. Start using >32-bit addresses when ready. When who is ready? Different people/organizations will be ready at different times. Some people will not be able to get IPv4 addresses so will be 'stuck' with being IPv4.1-only. Given the finite IPv4 addresses, some will move the IPv4 addresses to revenue-generating areas and will go IPv4.1-only internally—which is wh…

Switch to >32-bit when enough routers/hosts support it, i.e. they can parse the new packet format. We've already accomplished that with v6 long ago. In the meantime, ISPs that cannot afford enough 32-bit addresses for their customers can hand out 40-bit ones and perform a NAT-like translation. Same as what they're doing now with cgnat, except there's an exit strategy.

> Switch to >32-bit when enough routers/hosts support it, i.e. they can parse the new packet format. We've already accomplished that with v6 long ago.

And who gets to decide when "enough" devices support it? Who decides on that flag day?

* https://en.wikipedia.org/wiki/Flag_day_(computing)

The Tier 1s?

* https://en.wikipedia.org/wiki/Tier_1_network

Good luck coördinating that with the global Internet.

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

#177

Post by hot_gril »

bigstrat2003 wrote: post #167
hot_gril wrote: post #146

Earlier quoted context omitted.

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

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 address private IPs from the outside except on the random mapped ports. With v6, I'd instead be double-checking that my router firewall is doing its job, e.g. https://community.verizon.com/t5/Fios-Internet-and-High-Spee... . Even if the router turns out to be WAI, I shouldn't have to question that!

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

#178

Post by hot_gril »

throw0101b wrote: post #176
hot_gril wrote: post #174

Earlier quoted context omitted.

Switch to >32-bit when enough routers/hosts support it, i.e. they can parse the new packet format. We've already accomplished that with v6 long ago. In the meantime, ISPs that cannot afford enough 32-bit addresses for their customers can hand out 40-bit ones and perform a NAT-like translation. Same as what they're doing now with cgnat, except there's an exit strategy.

> Switch to >32-bit when enough routers/hosts support it, i.e. they can parse the new packet format. We've already accomplished that with v6 long ago. And who gets to decide when "enough" devices support it? Who decides on that flag day? * https://en.wikipedia.org/wiki/Flag_day_(computing) The Tier 1s? * https://en.wikipedia.org/wiki/Tier_1_network Good luck coördinating that with the global Internet.

Individual hosts decide. Same as how I can no longer visit httpS://chase.com on my ancient PC that doesn't support HTTPS, let alone a modern web renderer. Chase has left it behind.

ISPs also decide; they turn off their cgnats and start handing out /48s etc, at the latest when the cost of leasing /32s addresses exceeds the cost of being incompatible with a tiny few straggling hosts.

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

#179

Post by gunapologist99 »

mdaniel wrote: post #111
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…

Don't overlook SSM https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/session-... > which doesn't require sshd nor public access to get onto a machine and one can opt in to a bunch of audit logging if that's your jam. They also have some "ansible-y" behavior about running playbooks against groups of instances, but I haven't had good experiences with that process in order to recommend it. It's just a small bonus that…

SSM is powerful and convenient but very dangerous due to its huge surface area... I personally remove it by default.

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

#180

Post by hot_gril »

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 not possible. IPv4 addresses are 32-bit numbers. Once you change that, you're no longer "preserving existing addresses".

I am uniquely employee number 6100. That field is 32 bits in HR's database. If they make it 64-bit, I'm still 6100.

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

No it doesn't, it requires gradual cooperation, as the 4.1-compatible hosts will still speak v4 as needed. Same as how v6 stack support was added even to hosts not using it.

> It's more like "not needing NAT" than removing it; port mapping NAT is not a part of IPv4 (it's a hack on top of it), and it can be done identically in IPv6, but few do it on IPv6 since it's not necessary.

Yeah but the goal is to remove it. The feature set of v6, including random addressing, is intended to support p2p applications. The authors of ipv6 did not envision NAT being enable by default. Defaults and intent matter more than technical details here.

> IPv6 has done no such thing; the existing IPv4 blocks are still there.

They aren't there on practically any ipv6 network, despite an optional ipv6 extension for v4-mapped addresses. That's the critical difference vs what I've described.

Post reply on HN