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

131–140 of 245 posts

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

#131

Post by throw0101c »

worewood wrote: post #83
hristov wrote: post #63

Earlier quoted context omitted.

Currently my roomba is behind a nat and still insists on contacting their main data centers. And if i turn off the internet to my nat the roomba will run but none of the advanced cell phone related features of the roomba will work, even though my cell phone is connected to the same wifi network in the same nat as the roomba. So this is completely unrelated. IP addressing schemes will not change the business methods o…

> IP addressing schemes will not change the business methods of large consumer device companies. That's exactly the point; they market it as if it would make a plethora of new and innovative things happen but in reality they will allow none of it. So, it's pointless to rush adoption.

> That's exactly the point; they market it as if it would make a plethora of new and innovative things happen but in reality they will allow none of it.

How much innovation and applications have been stymied by artificial network-layer barriers:

> First is actually a more subtle issue... the Skype peer-to-peer network architecture elected certain nodes to be "supernodes", to help maintain the index of peers as well as handle parts of the NAT/firewall traversal for other peers.

* https://ip.topicbox.com/groups/ip/T9f6a724f4bcd6616-M0e99aba...

* https://arstechnica.com/information-technology/2012/05/skype...

CPE gear has gotten better hole punching over time (PCP, UPnP), but one still has to futz around with STUN/ICE/TURN.

We've invented entirely new protocols (QUIC) because of middleware boxes blocking things (SCTP, DCCP) and generally getting in the way.

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

#132

Post by blueflow »

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.

> You just support longer addresses, that's it.

There is no way a router that does not understand the address extension is able to route packages to the larger address spaces correctly. So this is not possible to do.

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

#133

Post by hot_gril »

snuxoll wrote: post #123
hot_gril wrote: post #121

Earlier quoted context omitted.

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.

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.

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

#134

Post by bigstrat2003 »

uxp8u61q wrote: post #58
exabrial wrote: post #54

Earlier quoted context omitted.

> 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). Do you really think Roomba is going to let you run your Robot Vacuum without contacting, er permission, from their data center in Virginia?

How is this at all related to global addressability?

It's not. OP has no idea what he's talking about.

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

#135

Post by wongarsu »

seanhunter wrote: post #6

Do the other cloud providers give you IPv4 endpoints for free? I didn't think that was the case. (ie I thought AWS was just falling into line with the others on charging). As for the "critical services not supporting IPv6" in the post I was quite surprised that it's such a short list of things that don't work - I would have expected more. They've obviously made a ton of progress.

Hetzner is charging 0.50€/month, compared to AWS's $3.60/month. Which I guess is in line with the usual price difference between the two, but usually AWS does a better job justifying the price difference.

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

#136

Post by throw0101b »

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.

> You just support longer addresses, that's it.

There is no "just" in this.

Copy-pasting from my other comment:

--

IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.

And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.

But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.

--

So "just" expanding IPv4 to IPv4+ ends up being the exact same amount of work as ended up with IPv6.

The only thing you could say with "just" more addresses is keeping ARP and the like (instead of DAD, etc).

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

#137

Post by nimish »

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…

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 entrenched, it's not 1982 with ARPANET connecting a handful of systems all managed by people who knew each other.

And DHCP does a bunch of stuff that's irritatingly dumb to do with IPv6, to the extent that v6 ended up shoving partial compromises _anyway_ like RDNSS.

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

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

#138

Post by saltminer »

hot_gril wrote: post #102
bluepizza wrote: post #84

Earlier quoted context omitted.

Home router NAT "layer of security" is equivalent to closing all ports. If an IPv6 home router closes all ports by default, then the same level of security is achieved.

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.

> I really do not want this.

Then disable it. IPv6 SLAAC privacy extensions are device-controlled, meaning neither your ISP nor your router can force you to use/not use them (unless they're so incompetent that they do things like hand out /128s).

I disable privacy extensions on my server so that I can give it a static IP within the prefix, so I can vouch that (at least on Linux) the process is quite simple.

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

#139

Post by hackmiester »

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.

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.

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

#140

Post by [deleted] »

exabrial wrote: post #55
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…

[flagged]

[deleted]
Post reply on HN