Live data from Hacker News

The world in which IPv6 was a good design

apenwarr.ca

21–30 of 199 posts

Re: The world in which IPv6 was a good design

#21
post #5
post #3

Ok, so QUIC or some other common layer 4/4+5 'Modern TCP over UDP for network compatibility' solution. Lets just throw away the concept of 'addresses' for authentication and actually use a cryptographic authentication identifier of somekind, combined with some mux iteration ID.

Check out ZeroTier It implements a virtual ethernet layer using cryptographic identities underneath. Here's the relevant section on the address computation from the manual: https://www.zerotier.com/manual.shtml#2_1_2

Zero tier is the most neglected network protocol I know. It deserves more attention.

Re: The world in which IPv6 was a good design

#22
post #18

What he's really arguing for is a circuit-switched network, so that connections can be persistent over moves. He just needs a unique connection ID. 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. If you could move an HTTP connection from one IP address to another on the fly, it could be…

> 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 private key.

When a destination node receives a packet from a neighboring node, and ACK would constitute the destination node’s signature over the received packet, thus making ACKs provable and portable (“this node has already received that packet, here’s the proof”).

Packet sources addresses would no longer be fake-able, as that would constitute breaking asymmetric cryptography.

The protocol would have no concept of a “connection”.

Routing would be left out of this protocol completely, and networks would use whichever routing protocols they find most efficient.

I wouldn’t be surprised if there were countless issues with a protocol like this, but something about it just seems so elegant to me that I haven’t stopped considering it yet.

Re: The world in which IPv6 was a good design

#23
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"

Hopefully some of the static-strictness features in the language will offer people tools to remove layers of abstraction... if they can get permission from humans to do the refactoring :p

Re: The world in which IPv6 was a good design

#24
post #4
post #3

Ok, so QUIC or some other common layer 4/4+5 'Modern TCP over UDP for network compatibility' solution. Lets just throw away the concept of 'addresses' for authentication and actually use a cryptographic authentication identifier of somekind, combined with some mux iteration ID.

Drop the idea of ports too. Every program gets its own IP Mentioning ideas like that at work get queer looks about how it'd be impossible to configure a firewall at that point But keep going further. End up with 128 bit CPU where every byte is IP addressable. Necessary security to block random outsiders from reading your memory, but capable of potentially running various parts remotely transparently

Really love this idea. IPv6 for every program, UUID for every session!

Re: The world in which IPv6 was a good design

#25
post #15
post #8

Part of the difficulty here - is you're not just upgrading the whole stack, you're instead layering on whatever stack is already there - its a needed part of deploying any new technology without replacing everything from the basement up. I'm not sure what this guy would do instead however - as someone with a decent networking background, I got completely lost in the end.

The author has a verbose writing style, and may not be a genius, but they are clearly familiar with networking protocols and do a good job explaining the general scene and history.

I just disagree with some of his premise - I don't think its feasible to get away from any and all layer two broadcast messages - even limiting yourself to IPv6 Mulitcast still leaves you with some pseudo-broadcast messages for either housekeeping or auto-discovery purposes - its part of what makes IP based networking in general work - and I'm talking services that run at layer four - that rely on that primitive to exist to make certain functionality happen.

Routing still adds complexity, and I see no way for it to not add complexity - he talks about each switch being a router for example - you then need a way to determine where a particular subnet you're trying to get to lies - which means a routing able (akin to a mac address table, but for prefix), and some way to feret out which interface a particular device lies (akin to arp, but instead searching for a prefix to route to) - in the end, you end up with the same primitives and complexity, but you've just moved it up a layer in the stack - which does nothing to get rid of complexity - it just adds to it. IP networks are often a tree in organizations - ethernet is often deployed with different topologies, relying to spanning-tree to give you more redundancy without extra configuration (at the expense of some delay on re-convergence)

I think also that so long as we're dragging along the legacies of the disparate layer one technologies (which in any case, would not and could not go away) - we're kinda stuck with what we have.

Re: The world in which IPv6 was a good design

#26
post #22
post #18

What he's really arguing for is a circuit-switched network, so that connections can be persistent over moves. He just needs a unique connection ID. 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. If you could move an HTTP connection from one IP address to another on the fly, it could be…

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

You should read about QUIC, which is designed to be able to do this, almost exactly like you describe. https://www.chromium.org/quic

Re: The world in which IPv6 was a good design

#27
post #4
post #3

Ok, so QUIC or some other common layer 4/4+5 'Modern TCP over UDP for network compatibility' solution. Lets just throw away the concept of 'addresses' for authentication and actually use a cryptographic authentication identifier of somekind, combined with some mux iteration ID.

Drop the idea of ports too. Every program gets its own IP Mentioning ideas like that at work get queer looks about how it'd be impossible to configure a firewall at that point But keep going further. End up with 128 bit CPU where every byte is IP addressable. Necessary security to block random outsiders from reading your memory, but capable of potentially running various parts remotely transparently

With NAT, this has essentially already happened. You could say IPv4 is actually 48-bit addressing, at least on the client side. For all useful purposes, NAT expanded every /24 or even /32 subnet by an extra 16 bits, which is the real reason we still haven't run out of IPv4 addresses.

That could be extended to the server side if we used something like SRV records instead of defaulting to port 80/443.

Re: The world in which IPv6 was a good design

#28
post #25
post #15

Earlier quoted context omitted.

The author has a verbose writing style, and may not be a genius, but they are clearly familiar with networking protocols and do a good job explaining the general scene and history.

I just disagree with some of his premise - I don't think its feasible to get away from any and all layer two broadcast messages - even limiting yourself to IPv6 Mulitcast still leaves you with some pseudo-broadcast messages for either housekeeping or auto-discovery purposes - its part of what makes IP based networking in general work - and I'm talking services that run at layer four - that rely on that primitive to e…

The point is that actually IPv6 already includes all the complexity you're talking about: complicated multicast to replace complicated broadcast, complicated routing to replace complicated bridging. The underlying problem with IPv6 is that it includes all this complexity because they expected to have to replace layer 2 bridging. But this never happened, so now we have all those features twice, which is worse.

Re: The world in which IPv6 was a good design

#29
"If, instead, we had identified sessions using only layer 4 data, then mobile IP would have worked perfectly."

Mobile IP can still work with the current infrastructure -- https://en.wikipedia.org/wiki/Mobile_IP

This proposal was basically a service which would host a static IP for you (similar to the LTE structure but with IP underneath instead of L2), and forward to whatever your "real" IP was using IP-in-IP encapsulation.

As the author states, layers are only ever added :)

Re: The world in which IPv6 was a good design

#30
post #25

Earlier quoted context omitted.

I just disagree with some of his premise - I don't think its feasible to get away from any and all layer two broadcast messages - even limiting yourself to IPv6 Mulitcast still leaves you with some pseudo-broadcast messages for either housekeeping or auto-discovery purposes - its part of what makes IP based networking in general work - and I'm talking services that run at layer four - that rely on that primitive to e…

The point is that actually IPv6 already includes all the complexity you're talking about: complicated multicast to replace complicated broadcast, complicated routing to replace complicated bridging. The underlying problem with IPv6 is that it includes all this complexity because they expected to have to replace layer 2 bridging. But this never happened, so now we have all those features twice, which is worse.

So IPv6 in essence is the future that was stillborn - we still plan and develop our networks for an IPv4 world, and then run IPv6 on top of them, correct?
Post reply on HN