Live data from Hacker News

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

apenwarr.ca

301–310 of 318 posts

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

#301
post #111

Earlier quoted context omitted.

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

For whatever reason (it's probably a mix of NAT, the extra routing needed for CGNAT, and other things) there is a measurable difference in time to first byte on v6. Apple measured it as 40%: https://www.zdnet.com/article/apple-tells-app-devs-to-use-ip...

(Also, doing things like loading a webpage requires many round trips, so even a small RTT difference multiplies to a bigger delay for total load time.)

You don't need to remove v4 to get benefits from v6. For example, you can handle inbound v4 on your load balancers to avoid needing to mess around with it on your entire VM fleet.

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

#302

Earlier quoted context omitted.

> Which means what is really necessary is a new IP protocol that will somehow, SOMEHOW (don't ask me how, I don't effing know) speak seamlessly to IPV4 and IPV6 You don't know how, and nobody knows how, because it's not possible to do. v4 simply does not support addresses longer than 32 bits. If it did, we wouldn't need v6 in the first place. Choosing not to do something that's impossible isn't hubris. Hubris is crit…

> You don't know how, and nobody knows how, because it's not possible to do. I think you misunderstood the comment, but at first reading, I did too. But on consideration, I do not think @AtlasBarfed meant that this hypothetical IPv12 or whatever (7 through to 10 are taken) would be able to talk to both in one protocol. It's well established that no seamless extension of the IPv4 4-octet address space was possible. I…

Based on "speak seamlessly to IPV4 and IPV6", I don't think I did. At the very least it would need to speak seamlessly to v4, which as you say is obviously not possible for any address length bigger than 32 bits.

> The real, the big question here is: was there some single obvious thing that IPv6 failed to do or failed to include that has made its uptake so slow? It's taken some 30 years to reach approximately half the IP market. That is not just "not good" - that's terrible.

Is it terrible though? Obviously it would be nice if it were faster, but what's the expected deployment time for something like v6?

There are about 30 billion network devices, arranged in hundreds of millions of separate networks managed by as many separate people. Noone has authoritative control over all of them. There's no hard deadline for v6 deployment (we saw with Y2K how much a deadline helps). Network effects work against it, and that's unavoidable because of v4's 32-bit limits.

I don't think humanity has ever tackled a migration project of this scope and scale before. So how can you know that it's going terribly?

I don't think there's an obvious thing we missed either, at least not in the set of things which work and are actually possible to do. I've talked to a lot of people about this, and their suggestions are basically either: not possible ("just get everyone to switch over all at once"), broken ("just pad v4 with some zeros"), or something v6 already did (frequently NAT64 or 6to4 but described in weird terms). Either there's a big conspiracy to keep the obvious thing a secret, or it doesn't exist.

> I welcome other pointers to articles not merely pointing out problems -- there are lots of those -- but proposing solutions.

Sigh... yes please. But solutions are hard, especially to unsolvable problems. Making a clickbaity article that points out the problems and says "somebody should have solved them" is easy, and as you can see from the response to this article and djb's each time they're posted, that's all people are interested in anyway.

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

#303

Earlier quoted context omitted.

Yeah, that's smart. There's no need for everything to be uniquely identified on the internet anyway, right? Why would someone halfway around the world need to be able to ping my smart fridge after all? Even for tech support purposes, people shouldn't have the ability to directly test my appliances firewall capabilities. Actually, now that I've done the math, why not just extend IPv4 into hexadecimal? Once again, none…

> what's not to love about it hexadecimal, unironically. the url of http://[2002:914b1:::1] is one of my major sticking points for IPv6. i'd rather just have it be 16 octets or even 8 decimal quartets where each thing is required. http://0.0.0.0.0.0.0.0.0.0.0.0.192.168.1.1:14246 would've at least looked a bit better than it is. would've been super easy too. imagine the convo: "what's google's DNS IP in IPvX?" "oh it'…

So, in my IPv4.1 suggestion, every address you currently know would work perfectly fine.

But then so would AE1.224.78.BC2

Sure, a little harder to remember maybe, but adding nearly a billion times as many IP addresses would alleviate the strain on the internet, be backwards compatible with IPv4 (but not forwards compatible, so most interior/home networks would use either a NAT or have a software ipv4-4.1 bridge software)

It would also be much more similar to IPv6 which would ease transition to full IPv6 if the human race survives long enough to ever make the jump. IPv6 is just more hexadecimal after all.

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

#304

Earlier quoted context omitted.

You've reinvented 6to4 and the 192.88.99.1 well-known anycast address.

So I think the difference here is then is gradual migration of the same IP stacks / infrastructure, and not introducing an entirely new "separate" stack. My only experience with IPv6 was converting an IPV4 distributed database to IPV6. It wasn't... fun. Looking up separate flags and settings, weird errors (thank the gods for stack overflow), frustration. Nowhere was it suggested, demonstrated, or detailed such a back…

That's what we have with v6. It's not entirely separate; it tends to be implemented together with v4 in the same stack of code and deployed on the same infrastructure. It's designed to allow you to migrate gradually.

> My only experience with IPv6 was converting an IPV4 distributed database to IPV6

I assume you mean patching the software to handle it... there are basically two socket APIs, the old one which was v4-only and the new one which works with any generic IP family. v6 had to add the second one because the first one was v4-only, but any replacement protocol for v4 would have had to do the same.

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

#305
post #169

Earlier quoted context omitted.

I read the article, also found it a bit confusing and wayward, and couldn't quite articulate why I disagreed with it at first, but I think I can now. - The "mobile IP" problem isn't IP's job and should not be. IP should be as stateless as possible because this makes it cheap and easy to add capacity and redundancy to a network. - IP addresses are assigned to interfaces, not people, computers, devices, applications, n…

> The "mobile IP" problem isn't IP's job and should not be. IP should be as stateless as possible because this makes it cheap and easy to add capacity and redundancy to a network. But, to be clear, many implementations of IP (both IPv4 and IPv6) do already have "mobile IPs." There's nothing stopping you from having "mobile IPs." They're just complex, and only work when everywhere the IP can move between all exists wi…

You can actually move anywhere with Mobile IPv6. If you move outside your AS, it automatically tunnels your traffic back to your home network with IPsec. There's also a feature called "Correspondent Node" which allows you to send traffic directly rather than tunnelling via your home network.

Which kind of makes it sound like IPv6 already has the feature the article thinks it should have had.

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

#306

Earlier quoted context omitted.

What, something like this? $ ping 64:ff9b::8.8.8.8 PING 64:ff9b::8.8.8.8(64:ff9b::808:808) 56 data bytes 64 bytes from 64:ff9b::808:808: icmp_seq=1 ttl=113 time=8.75 ms Seems like we already have something very much like that.

Yes, but most people don't even have access to that right now. https://www.akamai.com/internet-station/cyber-attacks/state-... Making a new system that will automatically go live, work transparently to the current system and is on by default as hardware is updated and replaced is a strong pathway forward to unsnarl the internet when you're stuck in this predicament. Pedantics won't solve the problem and just ensure t…

That would be a strong pathway forward indeed, if it were possible. Is it? Because your suggestion so far was something v6 already did, and it wasn't good enough for you.

Computers are the worst pedants in existence, so if it's not possible, you're not going to be able to do it... which means that not only is it not a useful suggestion, but it drains time and energy away from doing things which will work.

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

#307

I've only dabbled in IPv6, but the one thing that blew my mind was that you cannot set DNS automatically without DHCPv6. Other methods of "automatic addressing" are thus useless.

RFC8106 IPv6 Router Advertisement Options for DNS Configuration https://datatracker.ietf.org/doc/html/rfc8106

Ans what software do support it? There are tons of these IPv6 RFCs which is not supported by "common" software - Linux and FreeBSD daemons, nsd, unbound, etc.

How could I implement this in my home network, with off-the-shelf SOHO router or even something like OpenWRT / custom OSS-based "firmware"?

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

#308
post #169

Earlier quoted context omitted.

I read the article, also found it a bit confusing and wayward, and couldn't quite articulate why I disagreed with it at first, but I think I can now. - The "mobile IP" problem isn't IP's job and should not be. IP should be as stateless as possible because this makes it cheap and easy to add capacity and redundancy to a network. - IP addresses are assigned to interfaces, not people, computers, devices, applications, n…

> The "mobile IP" problem isn't IP's job and should not be. IP should be as stateless as possible because this makes it cheap and easy to add capacity and redundancy to a network. But, to be clear, many implementations of IP (both IPv4 and IPv6) do already have "mobile IPs." There's nothing stopping you from having "mobile IPs." They're just complex, and only work when everywhere the IP can move between all exists wi…

> You can move between multiple wireless APs in a conference hall, and have a layer-3 address that follows you as you switch network segments and thus acquire new layer-2 addresses (which means that the packets destined to that address are being dynamically re-routed at some upstream switch, as the address assignment changes.)

Is it possible to implement this at home, without paying a lot of money? I've tried it with UniFi AP (with software controller) and no luck :-(

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

#309

Earlier quoted context omitted.

> You don't know how, and nobody knows how, because it's not possible to do. I think you misunderstood the comment, but at first reading, I did too. But on consideration, I do not think @AtlasBarfed meant that this hypothetical IPv12 or whatever (7 through to 10 are taken) would be able to talk to both in one protocol. It's well established that no seamless extension of the IPv4 4-octet address space was possible. I…

Based on "speak seamlessly to IPV4 and IPV6", I don't think I did. At the very least it would need to speak seamlessly to v4, which as you say is obviously not possible for any address length bigger than 32 bits. > The real, the big question here is: was there some single obvious thing that IPv6 failed to do or failed to include that has made its uptake so slow? It's taken some 30 years to reach approximately half th…

Hmmmm.

I am not a network engineer (any more, thank the hypothetical deities) so I have no skin in this game.

But in the 1990s, I moved networks from IPX/SPX, or NetBEUI, or AppleTalk, or DECnet, and almost any combinations thereof, to IP. I added IP on top of existing networks. I migrated systems from 10base-2 to 10base-T to 100base-T. I stitched together WANs. Then I moved IP networks from static to DHCP, from no name resolution to DNS to WINS, and so on.

I am not a total rookie to this stuff.

So when you say

> I don't think humanity has ever tackled a migration project of this scope and scale before.

I have to disagree.

The IP rollout itself was bigger, and yet, it happened much, much faster.

We moved the networked world from a dozen protocols to IP, then we totally re-architected how IP worked, from static networks to `hosts` files to name resolution to dynamic IPs and dynamic name resolution.

Then we rejigged it all again for a world of proxies and gateways, and firewalls, and NAT.

You make out like this is some vast super-hard thing, but in fact, the world of networking is way older than many people in the modern IP-only world realise, and we've rebuilt it over and over and over again repeatedly.

When a new technology comes along that offer compelling advantages, then the world moves to it, not in one smooth operation but incrementally and piecemeal, but it happens.

It hasn't happened to IPv6 and my argument, and much more importantly the arguments of the Avery Pennarun here and of Dan Bernstein, are that it hasn't happened because IPv6 isn't good enough.

It's good but it only fixes 1 problem and that one, while big and important, is not the whole problem and it's not even the most important problem because there are workarounds for simple IP address starvation, and the workarounds are _good_ workarounds with their own advantages, and some of those advantages are compelling.

The world has, overall and on average, decided that IPv4 is good enough to mean it's not worth the pain of moving. It's better to fix what it already has.

It is the same issue as Plan 9 vs Unix.

Plan 9 is better by almost every objective measure, but Unix is good enough, so the world decided to stay with Unix rather than the pain of moving.

For me, what is an interesting question here is "could we fix Plan 9 to make it worth moving to?" The Plan 9 people don't care, though.

Similarly, although it's not my area, it's an interesting line of questioning to ask "what is wrong with IPv6 that the world didn't move to it, and can we fix that?"

But when someone proposes it, the IPv6 proponents treat it as heresy, not as a simple, relevant question.

That in itself is interesting too, IMHO.

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

#310

Earlier quoted context omitted.

RFC8106 IPv6 Router Advertisement Options for DNS Configuration https://datatracker.ietf.org/doc/html/rfc8106

Ans what software do support it? There are tons of these IPv6 RFCs which is not supported by "common" software - Linux and FreeBSD daemons, nsd, unbound, etc. How could I implement this in my home network, with off-the-shelf SOHO router or even something like OpenWRT / custom OSS-based "firmware"?

I'm using opnsense and it seems to have worked for my network.
Post reply on HN