Live data from Hacker News

The world in which IPv6 was a good design

apenwarr.ca

191–199 of 199 posts

Re: The world in which IPv6 was a good design

#191
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.

A fence also requires maintenance. An intact fence means someone wants the fence bad enough to put it there and maintain it.

IPv6 designs are only similar to the first half of that statement. If it's in IPv6, it's because someone wanted it there. The people designing IPv6 had almost 2 decades of operational experience running IPv4 to draw from. Things were intentional.

Re: The world in which IPv6 was a good design

#193
post #48
post #45

Earlier quoted context omitted.

Interesting idea. One thought would be add encryption and signing to the routing. Meaning unless you have the right permissions, your packets won't even get to the destination.

I'd much rather routing be about getting data from one known point to another. A /session/ should be able to be serviced by multiple routes, maybe with a preference (use the cheaper ones first, the faster ones first, etc) or maybe over time (in the case of mobile). Having connectivity based at the session level and having a single server be 'multi-homed' (many addresses, each conforming to a different outbound link)…

I think my though comes from the use case where you have thing1 and thing2 that you want to be able to communicate via the internet. But you would rather not be accessible from other devices.

Re: The world in which IPv6 was a good design

#194

This is an awesome read and hilarious if you have any historical knowledge of networking. +1 highly recommend even if all you want is a few chuckles. Well done.

BTW, the best read in networking is "The Elements of Networking Style" by Mike Padlipsky. https://en.wikipedia.org/wiki/Michael_A._Padlipsky It's hard to find a copy of that book but oh, man, if you know the stack and you lived through the ISO/OSI proposals, it's so so good. I got lucky and read that book after I had ported Lachman's streams based networking stack into the ETA-10 and SCO's Unix. I didn't know what I…

If HN doesn't upvote this to the stars, you suck. It is the essence of what HN likes, it's great tech presented well. Go find that book, go read about Mike, come on people, dig a little.

I don't care about the upvotes, I care that you go read. And read something that will help you see.

Maybe this thread is dead and I need to do a top level post about Mike.

Re: The world in which IPv6 was a good design

#195
post #51

>They have to be special, because an IP node has to be able to transmit them before it has an IP address, which is of course impossible, so it just fills the IP headers with essentially nonsense Not nonsense! The global IP broadcast is specified as 255.255.255.255 and is used by other protocols. The source IP address for the initial discovery is indeed 0.0.0.0, which is not intuitive, but the rest of the DHCP exchang…

> No, it's not an ethernet protocol. It's a layer-3 address assignment protocol that runs inside of IP, which is normally encapsulated in ethernet frames. You can have a remote DHCP server running any arbitrary L2 non-ethernet protocol and if it receives a relayed DHCP request it will reply with IP unicast perfectly fine with no ethernet involved.

This reminds me fondly of "frottle". A project from the Perth WAFreeNet - a city-wide wireless network back in the early 2000s. The "hidden node" problem with WiFi over these long distances is that each node cannot listen to prevent themselves talking over other nodes (CSMA/CD) -- because they cannot hear the other nodes - only the central access point.

There were costly commercial solutions (these days there are not so costly ones, for example many UBNT Ubiquiti products implement 'AirMax') so instead they implemented the Frottle project which would hold and then later transmit packets using a user-space iptables QUEUE driver when it received it's "token" / turn from the central AP over a TCP connection. The quote isn't on the webpage anymore it seems but it was something about a layer 3 & 4 solution to a layer-2 problem - a great and free hack that worked well :)

http://frottle.sourceforge.net/

Re: The world in which IPv6 was a good design

#197
post #135

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.

> One big UX mistake of IPv6: it was not made backward compatible with IPv4. The sin was committed when IPv4 was made and not initially designed to allow for variable / expanded address space -- it is not IPv6's fault. Adding an IP Option to IPv4 packets that could carry extra address bits was not an option either -- IP options aren't preserved much at all on the Internet. Furthermore, even if most routers didn't dro…

Ip options make it through the net/core just fine. It's generally edge networks where the ip option filtering occurs. This could be restored...so if someone wanted to suggest a backwards compatible extension to IPv4 that might be cool.

Re: The world in which IPv6 was a good design

#198
post #2

>One person at work put it best: "layers are only ever added, never removed." Find this in the software world as well. Something about the java culture seems especially fascinated with multiple layers of abstraction. Edit: Ok, some factions of the culture. " Convenient proxy factory bean superclass for proxy factory beans that create only singletons"

That is funny. I am doing some temporary consulting work in a Java shop. I created a layered and complicated solution to a complicated problem. I spent a lot of time defending the complexity of the solution as the necessity it was.

When the requirements appeared to change, I was all like, "Are you sure about that? That's great news because that means we can remove these layers from my solution and simplify the code a lot."

Apparently they had never heard about someone wanting to get rid of their own layers, because they just sat there in silence trying to come up with reasons to keep the (now) unnecessary layers.

In the end, I think they agreed that the new requirements must be incorrect, and the old ones still cover both cases. Imagine that! Throwing away new requirements solely to keep layers.

Re: The world in which IPv6 was a good design

#199

Earlier quoted context omitted.

BTW, the best read in networking is "The Elements of Networking Style" by Mike Padlipsky. https://en.wikipedia.org/wiki/Michael_A._Padlipsky It's hard to find a copy of that book but oh, man, if you know the stack and you lived through the ISO/OSI proposals, it's so so good. I got lucky and read that book after I had ported Lachman's streams based networking stack into the ETA-10 and SCO's Unix. I didn't know what I…

If HN doesn't upvote this to the stars, you suck. It is the essence of what HN likes, it's great tech presented well. Go find that book, go read about Mike, come on people, dig a little. I don't care about the upvotes, I care that you go read. And read something that will help you see. Maybe this thread is dead and I need to do a top level post about Mike.

Sigh, I think I screwed up this by being stupid. I still think that this is in the HN wheelhouse but I didn't help with my comments. My bad.

Please go read the book.

Post reply on HN