Live data from Hacker News

The world in which IPv6 was a good design (2017)

apenwarr.ca

111–120 of 318 posts

Re: The world in which IPv6 was a good design (2017)

#111
post #89

Earlier quoted context omitted.

I'm worried about the long tail. IPv6 won't actually be useful until more or less everything supports v6; as long as there are enough clients which don't support v6 servers need v4, and as long as there are enough servers which don't support v6 clients need v4. And until we can start disabling v4, v6 gives no advantage and only causes significant added complexity. I'm worried that the time when we can start removing…

> And until we can start disabling v4, v6 gives no advantage and only causes significant added complexity. v6 advantages: * If you're an ISP, you need more complex hardware for CGNAT-v4 if your traffic is huge. If you do support v6, netflix, youtube and majority of your traffic is already on v6, you can get by without upgrading your CGNAT Infra. * I suspect v6 should have faster initial connection - time to first byt…

* Until the transition is complete, I and everyone else is gonna have to use an ISP which provides a v4 address, whether they're end users or a server operators. Fair enough though that ISPs may have some incentive to making more people have v4+v6 (not that they seem to have realized...)

* I really don't think NAT could possibly make a noticeable difference in the time to first byte. My guess about what's "barely noticeable" would be a few hundred added milliseconds, my guess at what NAT would add would be a few milliseconds. Happy to be proven wrong though if there are any studies or experiments on the topic.

* I'm not sure what benefits there are to giving your VMs public v6 IPs when you still need to support incoming v4 connections.

Re: The world in which IPv6 was a good design (2017)

#112
post #89
post #65

Earlier quoted context omitted.

It's looking more like a slow victory than a failure: https://www.google.com/intl/en/ipv6/statistics.html People like to complain a lot about the new features in v6, but they don't make it any worse as a v4 replacement.

I'm worried about the long tail. IPv6 won't actually be useful until more or less everything supports v6; as long as there are enough clients which don't support v6 servers need v4, and as long as there are enough servers which don't support v6 clients need v4. And until we can start disabling v4, v6 gives no advantage and only causes significant added complexity. I'm worried that the time when we can start removing…

I find partial IPv6 support quite useful. For example, at home I have a lot of services where it it convenient if I can access them but it is not essential. I give those services IPv6 addresses. I have IPv6 at home, at work, on mobile. So it is not a big deal if I can't access them from some part of the world. With increasing prices of IPv4 addresses, I expect that more internal services will move to IPv6.

For services at home, where I do need IPv4 support, access over IPv6 is simpler and more robust. We can expect more of that in the future. Increasing prices of IPv4 addresses, certainly if for routing purposes you need a /24, may result in worse traffic engineering for IPv4.

Re: The world in which IPv6 was a good design (2017)

#113
post #106

One thing I’ve realized lately is that scarcity is actually a benefit of ipv4, much in the way of the maximum amount of bitcoins theoretically increases their value. Ipv4 addresses are being ranked by their reputation. This is a good thing, at least right now, as it makes scammers/spammers/hackers/ddosers lives more expensive to acquire fresh addresses. This can only exist when a shortage exists.

in ipv6 you can (should) grade whole subnets as end customers typically get whole /64s.

Not always though. Lower end VPS providers seem to be moving towards placing you on a shared /64. I run into issues on a particular Digital Ocean instance of mine where my IPv6 allocation is something like a /112 and it gets swept up in bans on the parent /64 because of other's bad behavior.

Then you have other providers like Vultr that do weird things like not statically route your /64 prefix to your instance which kind of defeats the entire point of having a /64.

Re: The world in which IPv6 was a good design (2017)

#114
post #80

Earlier quoted context omitted.

You're confusing cause and effect. They're very different precisely because of hacky nonsense like NAT.

How is (home) NAT making the problem more complex than a stateful firewall? You never want to have a policy where incoming connections/UDP streams are permitted by default to reach any random device on the network, regardless of whether that device has a routable IP or not. Now, CGNAT is a different beast and more worrisome from that point of view.

How do you have two different devices running a webserver on two different IPs at home with NAT?

Re: The world in which IPv6 was a good design (2017)

#115
post #96

I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.) I think the core argument can be summarised as this: 1. IPv6 is flawed because it has 2 main layers, but it needed 3. 2. It understands physical addresses, and i…

> As such it is not better enough than IPv4

That's the crux of it.

Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv7 - something that provides a meaningful incentive to upgrade.

Re: The world in which IPv6 was a good design (2017)

#116
post #78
post #65

Earlier quoted context omitted.

It's looking more like a slow victory than a failure: https://www.google.com/intl/en/ipv6/statistics.html People like to complain a lot about the new features in v6, but they don't make it any worse as a v4 replacement.

IPv6 adoption is just the traffic shift from desktop to mobile. IPv6 kinda makes sense in mobile because it solves a problem of needing multiple addresses per person (phone, tablet, gaming device, etc) and the whole stack is maintained by two entities (the phone OS manufacturer and the carrier). It probably would have worked even better if it was far less complex and only solved the problem that was needed. https://w…

> IPv6 adoption is just the traffic shift from desktop to mobile.

There are entire ISPs (in the US) that are IPv6-only for CPE because IPv4 is unavailable and they have to use expensive CG-NAT boxes to deal with IPv4:

* https://community.roku.com/t5/Features-settings-updates/It-s...

*https://news.ycombinator.com/item?id=35047624

Meanwhile India was 80% IPv6 as of a few months ago:

* https://news.ycombinator.com/item?id=32798003

The fact that the US and EU just happened to get a bunch of addresses first doesn't mean the rest of the world has the same options available.

More addresses are needed if everyone on the planet is to be able to connect.

Re: The world in which IPv6 was a good design (2017)

#117
post #90

Earlier quoted context omitted.

Well, tbh dual-stack is enabled in 70% of France's customers for example. If you start with a solid base (having a fixed IPv6 /56 delegation for example), or at least a dynamic allocation with IPv6-PD, then you'll see that it's way easier than IPv4 in the long end

I already get a headache when thinking of configuring firewall rules with a dynamic prefix for all my hosts.

I found building rules around a dynamic prefix to be simple enough on my old EdgeRouter once I found the poorly documented magic incantation to do so.

It isn’t possible on the UniFi system that replaced it. Who needs basic core functionality anyway.

Re: The world in which IPv6 was a good design (2017)

#118
post #80

Earlier quoted context omitted.

You're confusing cause and effect. They're very different precisely because of hacky nonsense like NAT.

How is (home) NAT making the problem more complex than a stateful firewall? You never want to have a policy where incoming connections/UDP streams are permitted by default to reach any random device on the network, regardless of whether that device has a routable IP or not. Now, CGNAT is a different beast and more worrisome from that point of view.

In a decade or two, everyone is going to be behind CGNAT. There are not enough IPv4 addresses.

Re: The world in which IPv6 was a good design (2017)

#119
post #80

Earlier quoted context omitted.

You're confusing cause and effect. They're very different precisely because of hacky nonsense like NAT.

How is (home) NAT making the problem more complex than a stateful firewall? You never want to have a policy where incoming connections/UDP streams are permitted by default to reach any random device on the network, regardless of whether that device has a routable IP or not. Now, CGNAT is a different beast and more worrisome from that point of view.

> How is (home) NAT making the problem more complex than a stateful firewall?

ICE/TURN/STUN: the address that your software sees on your laptop, desktop, home NAS is not the address that clients can connect to.

In both NAT and non-NAT you have to use UPnP/PCP to do hole punching, but with NAT you have to do a bunch of address-y stuff as well.

Re: The world in which IPv6 was a good design (2017)

#120
post #96

I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.) I think the core argument can be summarised as this: 1. IPv6 is flawed because it has 2 main layers, but it needed 3. 2. It understands physical addresses, and i…

> As such it is not better enough than IPv4 That's the crux of it. Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv7 - something that provides a meaningful incentive to upgrade.

IPv7 was used for the "TP/IX: The Next Internet" proposal from 1993: https://datatracker.ietf.org/doc/html/rfc1475

The next available version is IPv10

Post reply on HN