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

231–240 of 245 posts

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

#231

Post by Dylan16807 »

fsckboy wrote: post #230
Dylan16807 wrote: post #127

Earlier quoted context omitted.

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…

> 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. it enables a graceful transition period

What's the incentive to actually set it up, though?

You can do it right now as a graceful transition to IPv6. Running a pure IPv6 network with NAT64 or similar. But almost nobody does it. Why would your scheme be more tempting to them?

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

#232

Post by orangeboats »

hot_gril wrote: post #228
LinAGKar wrote: post #227

Earlier quoted context omitted.

Why carry over mistakes from IPv4 when they have an opportunity to fix them? When else are they gonna make those changes? And how would you propose making larger addresses without making them longer?

There isn't a strong enough consensus that these were mistakes, aside from making the address size too small. Maybe removing fragmenting was uncontroversial, but aside from that, ipv6 seems more complicated than ipv4 in many ways. Special kinds of addresses (link-local, v4-mapped, ULA, etc), special ways to write them, and so on. > And how would you propose making larger addresses without making them longer? Pre-exis…

>Special kinds of addresses

You give one example (ULA) and I can raise you four: 192.168.0.0/16, 10.0.0.0/8, 172.12.0.0/12. You give one example (LLA) and I can raise you another: 169.254.0.0/16.

So come on now with the "complexity" talks. It's obvious that you are not even educated in IPv6 technologies, or else you will be talking about NDP and others, not mere addresses.

>Pre-existing ones don't need to be longer

We cannot do that even if we wanted to do so.

Think about this: computer A supports only the "shorter IPv4" and computer B supports both the "shorter" and "longer IPv4". Now computer B has the IP "1.2.3.4.5". How can computer A, which supports only the shorter IP address, connect to computer B? By the magic of having hindsight? No.

Therefore: Congratulations! You have just repeated the current IPv4-IPv6 pain point without being aware of it. Which is fine, but note that in your comments you have tended to act like your solution is better than IPv6's.

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

#233

Post by Aerbil313 »

blueflow wrote: post #114
SamuelAdams wrote: post #53

Earlier quoted context omitted.

Once GitHub works with ipv6 I’ll start to take it seriously.

Once my IPv6 worked i stopped taking GitHub seriously.

Once my IPv6 works I’ll start taking IPv6 seriously.

Shame on you Turk Telekom and Turkcell. Still don’t support IPv6.

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

#234

Post by oarsinsync »

gray_-_wolf wrote: post #184
oarsinsync wrote: post #36

Earlier quoted context omitted.

Are there recommendations that result in IPv6 looking like something more than just IPv4 with bigger addresses? Yes. Is there anything stopping you from effectively running IPv6 networks the same way as you run IPv4 networks, but with larger address pools? No. You can do NAT66, you can do DHCPv6, you can run every network as a /120 (IPv6 equivalent of a /24 - 256 addresses) if you want to as well. You can even (outsi…

Sure, I don't have to, but everything in the stack assumes I would run it in the recommended way. I gave up trying to setup my LAN to support IPv6 after I wasted more than 2 hours on convincing my router, and devices behind it, to somehow work with the /128 address I got from my ISP. Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it? No, there is not, everyt…

> Sure, I don't have to, but everything in the stack assumes I would run it in the recommended way.

> This would not be a problem if it would be just bigger IPv4 and there still was NAT, DHCP and everything.

Irony, I remember life before DHCP/NAT44 defaults, and having to struggle so much to do it myself. Mind, this was 1997, and IPv6 was already a defined standard, which then never got any traction because NAT44 ended up being “good enough” for most people who didn’t think about what they lost in the process.

> Should it be technically possible? Yes, definitely. Is there any value for me in spending a lot of time on it?

There was a lot of value in me spending a lot of time and effort on setting up DHCP and NAT in my home environment in the 90s. Nobody else I knew thought it was worthwhile though, and thought I was insane.

There was a lot of value in me spending a lot of time and effort on dual stacking my LAN too. I see a parallel here that’s amusing to me :-)

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

#235

Post by hot_gril »

orangeboats wrote: post #232
hot_gril wrote: post #228

Earlier quoted context omitted.

There isn't a strong enough consensus that these were mistakes, aside from making the address size too small. Maybe removing fragmenting was uncontroversial, but aside from that, ipv6 seems more complicated than ipv4 in many ways. Special kinds of addresses (link-local, v4-mapped, ULA, etc), special ways to write them, and so on. > And how would you propose making larger addresses without making them longer? Pre-exis…

>Special kinds of addresses You give one example (ULA) and I can raise you four: 192.168.0.0/16, 10.0.0.0/8, 172.12.0.0/12. You give one example (LLA) and I can raise you another: 169.254.0.0/16. So come on now with the "complexity" talks. It's obvious that you are not even educated in IPv6 technologies, or else you will be talking about NDP and others, not mere addresses . >Pre-existing ones don't need to be longer…

> You have just repeated the current IPv4-IPv6 pain point without being aware of it

The current pain point with ipv6 is not simply that hosts/routers need to support the new packet header. Vast majority of them do by now, right? But going v6 means redesigning your network. If all the addresses, routing, etc were kept the same as before and switching just meant handling a different packet header, it'd be a much easier transition. Then once everyone's on v4.1, people could start using longer addresses.

> It's obvious that you are not even educated in IPv6 technologies, or else you will be talking about NDP and others, not mere addresses.

They're mere addresses in ipv4, but not so in ipv6. ULAs are routed specially, basically as a replacement for NAT. See, I can use jargon too, but it doesn't matter here. From a common sense standpoint, there's no way that making the address field bigger requires changing all existing addresses.

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

#236

Post by orangeboats »

hot_gril wrote: post #235
orangeboats wrote: post #232

Earlier quoted context omitted.

>Special kinds of addresses You give one example (ULA) and I can raise you four: 192.168.0.0/16, 10.0.0.0/8, 172.12.0.0/12. You give one example (LLA) and I can raise you another: 169.254.0.0/16. So come on now with the "complexity" talks. It's obvious that you are not even educated in IPv6 technologies, or else you will be talking about NDP and others, not mere addresses . >Pre-existing ones don't need to be longer…

> You have just repeated the current IPv4-IPv6 pain point without being aware of it The current pain point with ipv6 is not simply that hosts/routers need to support the new packet header. Vast majority of them do by now, right? But going v6 means redesigning your network. If all the addresses, routing, etc were kept the same as before and switching just meant handling a different packet header, it'd be a much easier…

>But going v6 means redesigning your network.

>If all the addresses, routing, etc were kept the same as before

It is a natural consequence of having a greater address space.

If you decide to expand the address to become 128-bits long (heck, even 64 bits), you will also expand the routing table and risk overwhelming the limited memory of some routers.

Hence, we need to find ways to aggregate the routes and make the route table more efficient, and that's what you are looking at with IPv6 addressing. The /64 per network requirement effectively cuts the size of your route table in half, for example.

But even so... your point that:

>Then once everyone's on v4.1, people could start using longer addresses.

...is incredibly naïve. It took decades to have everyone support HTTPS, and to this day we still have HTTP-only websites.

>ULAs are routed specially, basically as a replacement for NAT.

For god's sake, no. It is better to think ULAs are specifically used for internal communications than to think they are for NATs.

Like I said, you really don't understand IPv6 at all, stop pretending that you are, lest you repeat all the same so-claimed "mistakes of IPv6" in your own solution.

>no way that making the address field bigger requires changing all existing addresses.

Except that when you are moving pre-existing machines out of a NATted network, you will need to give them new addresses, and then you realize that you have to renumber everything anyways in the end - otherwise you will have locally proximal machines in vastly different subnets.

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

#237

Post by hot_gril »

orangeboats wrote: post #236
hot_gril wrote: post #235

Earlier quoted context omitted.

> You have just repeated the current IPv4-IPv6 pain point without being aware of it The current pain point with ipv6 is not simply that hosts/routers need to support the new packet header. Vast majority of them do by now, right? But going v6 means redesigning your network. If all the addresses, routing, etc were kept the same as before and switching just meant handling a different packet header, it'd be a much easier…

>But going v6 means redesigning your network. >If all the addresses, routing, etc were kept the same as before It is a natural consequence of having a greater address space. If you decide to expand the address to become 128-bits long (heck, even 64 bits), you will also expand the routing table and risk overwhelming the limited memory of some routers. Hence, we need to find ways to aggregate the routes and make the ro…

> Hence, we need to find ways to aggregate the routes and make the route table more efficient, and that's what you are looking at with IPv6 addressing. The /64 per network requirement effectively cuts the size of your route table in half, for example.

Maybe I'm misinterpreting what you're saying here, but expanding your address space doesn't suddenly mean you have more routes to deal with. Like, ISP is routing all 1.2.3.4/32 traffic to my router; they don't care what addresses it forwards to underneath that. The ISP could support more customers by handing out /40s, but that's a gradual increase.

Unless you're saying that just supporting the longer field means more memory is used for the existing addresses (true), but idk if that means you have to re-optimize all your routes.

> ...is incredibly naïve. It took decades to have everyone support HTTPS, and to this day we still have HTTP-only websites.

Most sites are HTTPS-only because it's safe to assume every client will support it. Now how many big websites are ipv6-only?

HTTPS is the networking migration success story I like to point to, in fact. Just the right amount of force was applied, including banning old TLS versions later.

> For god's sake, no. It is better to think ULAs are specifically used for internal communications than to think they are for NATs.

I didn't say they are for literal NATs. They are replacement for the private networking feature of NAT, where your LAN hosts aren't reachable from WAN.

> Except that when you are moving pre-existing machines out of a NATted network, you will need to give them new addresses, and then you realize that you have to renumber everything anyways in the end - otherwise you will have locally proximal machines in vastly different subnets.

If you're moving pre-existing machines out of a NATted network. Not everyone has to.

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

#238

Post by orangeboats »

hot_gril wrote: post #237
orangeboats wrote: post #236

Earlier quoted context omitted.

>But going v6 means redesigning your network. >If all the addresses, routing, etc were kept the same as before It is a natural consequence of having a greater address space. If you decide to expand the address to become 128-bits long (heck, even 64 bits), you will also expand the routing table and risk overwhelming the limited memory of some routers. Hence, we need to find ways to aggregate the routes and make the ro…

> Hence, we need to find ways to aggregate the routes and make the route table more efficient, and that's what you are looking at with IPv6 addressing. The /64 per network requirement effectively cuts the size of your route table in half, for example. Maybe I'm misinterpreting what you're saying here, but expanding your address space doesn't suddenly mean you have more routes to deal with. Like, ISP is routing all 1.…

>doesn't suddenly mean you have more routes to deal with.

Routing tables don't magically change their structures according to the routes either. Think about this: the routing table must provide at least 40 bits of space to accomodate for possibly 40-bit routes or 32-bit routes. After all, the router cannot tell what routes you are putting in when it is manufactured.

If you increase your address space by any number of bits, your routing table must necessarily increase its size.

>I didn't say they are for literal NATs.

Private networking is private networking, NAT is NAT. The fact that you are conflating those two makes me highly worried, especially in the context of Internet Protocol designing.

>If you're moving pre-existing machines out of a NATted network. Not everyone has to.

Now here is your very fundamental misunderstanding of any next-generation Internet Protocol! If we are not getting rid of NAT, there is no point in introducing larger address space in first place.

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

#239

Post by hot_gril »

orangeboats wrote: post #238
hot_gril wrote: post #237

Earlier quoted context omitted.

> Hence, we need to find ways to aggregate the routes and make the route table more efficient, and that's what you are looking at with IPv6 addressing. The /64 per network requirement effectively cuts the size of your route table in half, for example. Maybe I'm misinterpreting what you're saying here, but expanding your address space doesn't suddenly mean you have more routes to deal with. Like, ISP is routing all 1.…

>doesn't suddenly mean you have more routes to deal with. Routing tables don't magically change their structures according to the routes either. Think about this: the routing table must provide at least 40 bits of space to accomodate for possibly 40-bit routes or 32-bit routes. After all, the router cannot tell what routes you are putting in when it is manufactured. If you increase your address space by any number of…

> If you increase your address space by any number of bits, your routing table must necessarily increase its size.

So you're talking about the second thing I mentioned. Supporting N users requires storing at least Nlog(N) bits of addresses in total. Going to /40 doesn't seem like a big enough increase to require redoing all the routes. And even if it is, an ISP could even roll out v4.1 sticking with /32s for now, keeping their routing tables exactly the same and leaving the expansion effort for later.

> Private networking is private networking, NAT is NAT. The fact that you are conflating those two makes me highly worried, especially in the context of Internet Protocol designing.

In IPv4, a very common reason you'd have a private network is because of a NAT, even though they aren't the same concept. To help get rid of NAT in IPv6, they added ULAs. That's all I mean.

> If we are not getting rid of NAT, there is no point in introducing larger address space in first place.

The point is that we're running out of addresses, like ipv6 proponents keep saying. Everyone who needs public IPs for any reason should be able to obtain them cheaply. This doesn't mean that NAT needs to disappear everywhere, though some users (like ISPs running CGNATs) might be happy to either ditch their NATs or split them up later on.

And this is what I said in my original comment, ipv6 has extra goals (like removing NAT day 1).

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

#240

Post by orangeboats »

hot_gril wrote: post #239
orangeboats wrote: post #238

Earlier quoted context omitted.

>doesn't suddenly mean you have more routes to deal with. Routing tables don't magically change their structures according to the routes either. Think about this: the routing table must provide at least 40 bits of space to accomodate for possibly 40-bit routes or 32-bit routes. After all, the router cannot tell what routes you are putting in when it is manufactured. If you increase your address space by any number of…

> If you increase your address space by any number of bits, your routing table must necessarily increase its size. So you're talking about the second thing I mentioned. Supporting N users requires storing at least Nlog(N) bits of addresses in total. Going to /40 doesn't seem like a big enough increase to require redoing all the routes. And even if it is, an ISP could even roll out v4.1 sticking with /32s for now, kee…

>And this is what I said in my original comment, ipv6 has extra goals (like removing NAT day 1).

Extra goals? Removing NAT? Come on now... Don't act like NAT was invented along with the Internet itself, you know it wasn't.

And again, never ever conflate NAT with private networks.

NAT is a packet-modifying technique that is closely associated with stateful firewalls, but it still ain't firewall. If you want private networks, you would actually use a firewall, not NAT.

Post reply on HN