Live data from Hacker News

Tell HN: IPv6-only still pretty much unusable

news.ycombinator.com

621–630 of 649 posts

Re: Tell HN: IPv6-only still pretty much unusable

#621
post #507
post #474

Earlier quoted context omitted.

I am not a network engineer, but for about 20 years I have wondered why we didn't 'just' do something like: 1. Include an extra 32-bits of address information as an IP options header. Call it an IP4.4 packet. 2. (I think?) IP4.4 packets would therefore happily travel over existing IP4 infrastructure. 3. Each existing IP4 address becomes a potential IP4.4 network with 32-bits of address space behind it. IP4.4 aware ro…

"Happily travel" and get to the wrong place? What's the point of that?

Happily traverse the existing IP4 Internet, to an IP4.4 aware edge network. The point is that you don't need to modify any IP4 networks between the IP4.4 aware origin and destination routers.

Re: Tell HN: IPv6-only still pretty much unusable

#622
post #474

Earlier quoted context omitted.

I am not a network engineer, but for about 20 years I have wondered why we didn't 'just' do something like: 1. Include an extra 32-bits of address information as an IP options header. Call it an IP4.4 packet. 2. (I think?) IP4.4 packets would therefore happily travel over existing IP4 infrastructure. 3. Each existing IP4 address becomes a potential IP4.4 network with 32-bits of address space behind it. IP4.4 aware ro…

We had a IPv6 transition mechanism that worked a bit like this (but nicer), it was phased out when native v6 support was deemed widespread enough. https://en.wikipedia.org/wiki/6to4

Thanks for that. As a transition-to-IP6 technology that makes a lot of sense, but I think it required a lot of prerequisite technology and work (i.e. IP6 itself). The hack I described could have been implemented on top of existing IP4 codebases.

Re: Tell HN: IPv6-only still pretty much unusable

#623
post #474

Earlier quoted context omitted.

I am not a network engineer, but for about 20 years I have wondered why we didn't 'just' do something like: 1. Include an extra 32-bits of address information as an IP options header. Call it an IP4.4 packet. 2. (I think?) IP4.4 packets would therefore happily travel over existing IP4 infrastructure. 3. Each existing IP4 address becomes a potential IP4.4 network with 32-bits of address space behind it. IP4.4 aware ro…

What happens when your 4.4 packet hits a router box somewhere out there that doesn’t understand 4.4? Where’s it going to send that packet? To the wrong address (or potentially even create an infinite loop). Now what?

> or potentially even create an infinite loop

I think that's what TTL is for. Without it, it would be entirely possible to have infinite loops between IP4 networks.

Re: Tell HN: IPv6-only still pretty much unusable

#624

Earlier quoted context omitted.

You're basically doing carrier grade NAT for that, the same thing that is apparently tooootallly acceptable to the ipv6 people for their big success story: mobile. The only success story of ipv6 leads us to the solution: backbone-level CGNAT and other hacks, then impose the economic cost on IPV4-only carriers and endusers.

Indeed, your system would require NAT4.44 as a transition mechanism, just like NAT64 is needed now. It gets no benefit over IPv6, and none of the other benefits like SLAAC. So, what's the point? It's no easier to migrate to, and once we're migrated is worse.

If a source behind an IP4.4 router sent a packet to an IP4 destination, then yes, the source router would need to apply NAT to the source address. But this is already a standard IP4 router capability, and I think that most connection origins on the internet are already behind a NAT.

I don't agree that it wouldn't have been easier to migrate. No changes would have been needed within retail ISPs for starters. Source code changes to existing IP4 stacks would have been minimal, without requiring a whole new stack like IP6. Practical migration requires only that the source and destination networks be IP4.4 aware.

The idea might make less and less sense over time, but if we'd done this 20 years ago we would have reliably had all the address space we needed 10 years ago, no further transition necessary. So much money spent on IP6 could have been saved, not to mention the opportunity cost of IP4 space being hard to get in recent years.

Re: Tell HN: IPv6-only still pretty much unusable

#625

Earlier quoted context omitted.

On their leased hardware, it is enabled from what I've seen. And if you are running your own modem and router, you will get IPv6 if you configure your setup to request it (via DHCP). They will even give you a /60 if your DHCP client asks for it.

Even? /60 should be the minimum , even home users usually have a couple subnets (guest networks for example, sometimes one for the router's WAN link) and you want the boundary to be on a nybble boundary

A /60 network consists of 295,147,905,179,352,825,856 addresses. I think most users will probably be fine with that.

Re: Tell HN: IPv6-only still pretty much unusable

#626
post #513

Earlier quoted context omitted.

Because we don't want to use 20 IPv4 addresses for the cluster of 20 nodes, when we only have so much addresses assigned to our institute. We could have gone the NAT route, but then we'd need to have some router. And if we designate the head node as router, all traffic would not go through the switch directly, but first through the head node and then out. This would mean that the nodes are less independent, as they h…

But you still need NAT right? To support outbound connections from the worker nodes?

So long as you're using a /64 routed to you from your upstream, nope, you won't need NAT.

Re: Tell HN: IPv6-only still pretty much unusable

#627
post #625

Earlier quoted context omitted.

Even? /60 should be the minimum , even home users usually have a couple subnets (guest networks for example, sometimes one for the router's WAN link) and you want the boundary to be on a nybble boundary

A /60 network consists of 295,147,905,179,352,825,856 addresses. I think most users will probably be fine with that.

This is v6; nobody counts individual IPs, because the answer is always "enough".

A /60 is only 16 /64s (i.e. 16 subnets), and that's not always enough.

Re: Tell HN: IPv6-only still pretty much unusable

#628
It's unlikely that IPv6 will be deployed widely for a few reasons. First, many companies and organizations have already invested heavily in IPv4 infrastructure, so it would be costly and time-consuming for them to switch to IPv6. Additionally, IPv4 and IPv6 are not interoperable, which means that devices using one protocol cannot communicate with devices using the other. Finally, there are still a large number of available IPv4 addresses, so there is no immediate need to switch to IPv6. Until these issues are addressed, it's unlikely that IPv6 will be widely deployed.

Re: Tell HN: IPv6-only still pretty much unusable

#629
post #125

Earlier quoted context omitted.

I mean, v6 is still mostly a failure, so (rightly or not) the situation is going to be blamed on the people that have been pushing v6. That's just the cost of trying to push the entire world towards a new standard. (I know that v6 has been a success within datacenters and such.)

by what definition would you call ipv6 "mostly a failure"? 30-40% global eyeball network (to the end user) adoption after ~10 years of active deployment, against very vocal opposition seems commendable enough to me.

More like 15 years of active deployment, and I'd expect levels at 90%. The world changed after IPv6 with smartphones that are controlled by a select few carriers, so it's easy to deploy IPv6 in which they're in dire need.

But the rest of the networks: enterprises, hosting providers, cloud providers, ISPs really don't give a shit. It's merely a cost centre or a burden.

Re: Tell HN: IPv6-only still pretty much unusable

#630
post #622

Earlier quoted context omitted.

We had a IPv6 transition mechanism that worked a bit like this (but nicer), it was phased out when native v6 support was deemed widespread enough. https://en.wikipedia.org/wiki/6to4

Thanks for that. As a transition-to-IP6 technology that makes a lot of sense, but I think it required a lot of prerequisite technology and work (i.e. IP6 itself). The hack I described could have been implemented on top of existing IP4 codebases.

Sure, we could have had hacks that would have been faster to implement, but there isn't reason to believe it would have helped. The bottleneck was never in the code. Routers and OSes got v6 support ages ago and it's been working in lots of edu & gov networks all over the world for 20+ years. ISPs just haven't been enabling it.

Lukewarm deployment incentives for ISPs, lack of pull from device/app makers, etc have been the main problems. Apps adapted to the NAT world quickly, users forgot what capabilities they lost and started to fall into the NAT = security cognitive trap.

Post reply on HN