Live data from Hacker News

The world in which IPv6 was a good design

apenwarr.ca

171–180 of 199 posts

Re: The world in which IPv6 was a good design

#171
post #75

Earlier quoted context omitted.

Backwards compatibility can not work. You can not answer an IPv6 packet with IPv4. There is no room in the header for the much bigger source/return address. You can try to do hacks like NAT (like you probably do in your home IPv4 network, which breaks/stops any peer-2-peer protocol). The IPv6 version is called DNS64/NAT64, and it breaks even more things, e.g. DNSSEC. Because it not only requires network address trans…

I don't mean it that way. Yes, on-the-wire format would have changed, maybe there would have been a required transition from v4 to v4.1, which could then have been backward compatible to v6. To be fair, I don't think the authors of v6 at the time realized how much friction an alternative IP stack would cause.

That .1 change has __all__ of the same (and maybe a bit more) problems as the move to v6.

(Because it makes things even more complicated, now you'll have not two incompatible but about three things.)

And of course the problem is/was of economics. No incentive to change, v4 is good enough for now, for the incumbents. And even if large companies with new users were running out of v4, they can afford trading netblocks and/or carrier grade NAT devices, both are cheaper than telling others to upgrade (and you'd lose customers/subscribers otherwise).

Re: The world in which IPv6 was a good design

#172
post #132

Earlier quoted context omitted.

I disagree. Over-engineering is epidemic in modern software. That being said: in this specific case you're right.

That's usually the challenge, isn't it? differentiating the specific cases where the seemingly pointless solution is actually the best way to solve a problem from the cases where the problem could be solved a different way that eliminates the need for the seemingly pointless solution from the cases where the solution is actually just a pointless flourish.

Essential complexity vs. accidental complexity

Re: The world in which IPv6 was a good design

#173
post #22

Earlier quoted context omitted.

> One amusing possibility would be to do this at the HTTPS layer. With HTTPS Everywhere, most HTTP connections now have a unique connection ID at the crypto layer - the session key. As a network-ignoramus, who likes cryptography, I’ve long dreamt of a networking protocol where endpoints are defined, primarily, by a public key. All messages would be encrypted with the destination public key, and signed by the source p…

> As a network-ignoramus, who likes cryptography, I’ve long dreamt of a networking protocol where endpoints are defined, primarily, by a public key. All messages would be encrypted with the destination public key, and signed by the source private key. See https://zerotier.com/

Yup. It's also open source:

https://github.com/zerotier/ZeroTierOne

Re: The world in which IPv6 was a good design

#174

One big UX mistake of IPv6: it was not made backward compatible with IPv4. (v6)0.0.192.168.1.10 == 192.168.1.10(v4). This simple design when planning and rolling it out would have meant incrementally updating the networking stack to also support v6. Now it turns out v4 and v6 are completely different, and no one has a big enough reason to make the change until everyone else makes the change. Hard chicken-egg problem.

With the way IP Routing works, every router on the path makes a routing decision. So two people on the "new IPv4" would be unable to talk to each other if even one router on their path doesn't understand the new format. Not to mention that to be fully compatible, you'd need a way for a person with the address "0.1.192.168.1.10" to talk to an IPv4 only client on 192.168.1.10. Then there are switches and routers that m…

Maybe you want to check out https://nlnet.nl/NGI - and make a suggestion...

Re: The world in which IPv6 was a good design

#176
It would be interesting to put that post into Genius and annotate its errors. At some level the premise is both true and false.

I lived the IPV6 debate, I went to IETF meetings, I worked on network services that would be affected one way or the other, I debated with others the various ways to "improve" or "replace" V4 to get a better system. And all through that time, while everyone felt there would be billions and billions of IP addresses, I was not aware of any discussion of dynamic routing such that a network endpoint could be found anywhere in the world without configuration. For everyone at the time felt network infrastructure was fixed, and network clients moved.

In that way a network client would move from one network to another, and then in that new network it would have to establish itself and then advertise somehow its new status. Everyone agreed that there would be some disruption during this change of status but things like TCP were designed to tolerate lossy networks. The network would adapt.

That pre-supposes a lot of little networks, with their own sets of rules. Except that isn't the way cellular carriers think, they have one network and your relationship to it rarely changes. If you aren't on their network you are 'roaming' and there are fixed rules in place for that. So they trade a lot of tracking and management for ease of use on the customer. And it enables some annoying things like 'header injection' in Verizon's case.

Dumb networks versus smart networks. AT&T's original switched network around the world vision versus Bob Metcalf's self organizing collection of independent nodes following a small set of rules. Architecturally its a debate that has been going on for a long long time.

Re: The world in which IPv6 was a good design

#177
post #150

Earlier quoted context omitted.

Reliable rule, and not just for software. Seems like a good place for mentioning 'Chesterton's Fence'.... In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern…

Sometimes, a thing is there because it's there, and nobody knows the original purpose, so by Chesterton, nobody would be able to tear it down, because nobody can see the use of it. Chesterton's Fence neatly saves the utterly pointless fences in our lives, regardless of the damage they can cause.

I think your conclusion is a result of oversimplifying the concept of Chesterton's Fence. The idea can be restated as "Don't remove what you don't understand", but that doesn't imply "This thing is impossible to understand and may never be removed". A lack of understanding at a point in time doesn't imply a permanent inability to understand.

Applied properly, the principle of Chesterton's Fence should provide you with the impetus to observe and learn about the subject. In software, that could involve creating/improving tests, diagramming method/API invocations, monitoring network traffic, etc. As a result of your observations, you should understand the subject deeply enough to determine whether it can be removed safely. If it can't be safely removed, you now have documentation justifying its existence (which may, in some cases, form the basis for a plan to migrate, deprecate, and remove).

Re: The world in which IPv6 was a good design

#178
We have to stop IPv6 debate, it's already the reality. Even if you don't like it, even if you think it's ugly - doesn't matter. US IPv6 mobile traffic passed 50% some time ago https://engineering.linkedin.com/blog/2017/07/linkedin-passe... IPv6 at least on mobile is real and many of us even didn't notice it's there.

Re: The world in which IPv6 was a good design

#179

Is anyone else shocked at the low level of adoption of IPv6? I remember how in the late 90s people were saying we were going to run out of addresses and everyone need to migrate to IPv6 ASAP. Now, it seems that IPv4 is going to be around for a long while.

US IPv6 adoption is above 50% for mobile networks. Wouldn't call it 'low level'

Re: The world in which IPv6 was a good design

#180
post #50

>In truth, that really is just complicating things. Now your operating system has to first look up the ethernet address of 192.168.1.1, find out it's 11:22:33:44:55:66, and finally generate a packet with destination ethernet address 11:22:33:44:55:66 and destination IP address 10.1.1.1. 192.168.1.1 is just a pointless intermediate step. This is completely wrong, it's not pointless. First, this can be used to easily s…

> this would mean you would either have to spoof the MAC on the second router

But isn't this what CARP[1] and HSRP[2] essentially do anyway? Seems like they already found a way around that.

[1]: https://www.freebsd.org/doc/handbook/carp.html

[2]: https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-ro...

Post reply on HN