Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The world in which IPv6 was a good design

apenwarr.ca

Post reply on HN
Print view View original

51–60 of 199 posts

Re: The world in which IPv6 was a good design

#51

Post by hueving »

>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 exchange is handled with real IP addresses like normal IP traffic. DHCP is very much an IP protocol (see DHCP relay for how it transits IP networks).

>Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that.

Ugh, come on! RARP doesn't provide you with a route to get out of the network or other extremely useful things like a DNS server.

>and DHCP, which is an IP packet but is really an ethernet protocol, and so on.

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.

Re: The world in which IPv6 was a good design

#52

Post by okket »

> Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that.

Actually, no. You can only set an IP address with RARP, not even a netmask (RARP comes from pre-CIDR age) or other important stuff like default gateway, DNS server, etc like you can with DHCP.

Re: The world in which IPv6 was a good design

#53

Post by runeks »

apenwarr wrote: post #26
runeks wrote: 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…

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

I’d really like to remove the idea of a “connection” from the protocol, and leave that to the routing protocol. In other words, the proposed protocol would be purely logical, and would only define what constitutes a sender (one who can sign a packet with its source public key) and a receiver (one who can sign a packet with its destination public key).

Again, I’m fairly network-ignorant, but as far as I can see this constitutes an inversion of the current architecture: routers need to be aware of signatures, such that they don’t deliver an invalid packet (bad signature) to a destination. So the logical layer would be the lowest one, and a router that delivers a packet with a bad signature would be considered defunct.

The funny thing about the current architecture, in my view, is that the correct destination of an HTTP TLS packet is hidden (encrypted) inside the application data (“Host: google.com”). So routers rely on IP addresses to figure out where the packet needs to go, while the logical destination is only visible to the receiver once it decrypts the packet.

The idea would be moving this information out of the application data, making it cryptographically sound (public key is destination, not domain name), and making routers aware of it such that they know whether a packet was delivered to the correct destination by whether it responds with a valid signature.

Re: The world in which IPv6 was a good design

#54

Post by hueving »

>Network operators basically choose bridging vs routing based on how fast they want it to go and how much they hate configuring DHCP servers, which they really hate very much, which means they use bridging as much as possible and routing when they have to.

Very rarely does a network operator use bridging to avoid configuring DHCP. All modern protocols are built on IP so you still need an addressing scheme and most people want the Internet so the 169 auto addressing is out. So even in big bridged networks, you still have a DHCP server. In fact, you configure less DHCP in a big bridged network than DHCP for a ton of tiny networks.

The advantage to big bridging networks is that you have to setup very little routing (just the router to get in and out). If you routed between every port on the network, there would be an excessive amount of configuration involved to setup prefixes on every single interface.

Re: The world in which IPv6 was a good design

#55

Post by hueving »

>And nowadays big data centers are basically just SDNed, and you might as well not be using IP in the data center at all, because nobody's routing the packets. It's all just one big virtual bus network.

The opposite trend is true in large data centers. L3 fabrics where everything is routed have become extremely popular because BGP (or custom SDN setups) can be used to migrate IPs and you get to utilize multiple paths (rather than the single path offered by STP convergence).

Re: The world in which IPv6 was a good design

#57

Post by naasking »

runeks wrote: post #22
Animats wrote: 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…

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

Re: The world in which IPv6 was a good design

#58

Post by XorNot »

minhoryang wrote: post #24
__s wrote: post #4

Earlier quoted context omitted.

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!

With IP-per-container we're pretty close to this already. systemd could launch every service on my system into it's own network namespace with a unique IPv6 address + NAT via my IPv4.

Might be an interesting weekend project sometime.

Re: The world in which IPv6 was a good design

#59

Post by Dagger2 »

apenwarr wrote: post #33
akshayn wrote: post #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 encapsu…

That's basically just an IPIP tunnel. It works, but adds tons of latency. A "good" mobile IP (which would be possible with eg. QUIC) would add no per-packet latency.

Correspondent node functionality in Mobile IPv6 does exactly that, by sending the packets directly between the two nodes involved. Basically it works by associating the connection with a 128-bit GUID instead of with the node's current network address, which allows the network address to change without breaking connections.

So... basically exactly what the suggested solution would look like, if it was modified to work with all protocols and not just TCP/UDP.

Re: The world in which IPv6 was a good design

#60

Post by pyvpx »

loeg wrote: post #14
mjevans wrote: 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.

Why does it have to be over UDP at all? Couldn't we just role a new layer 4 protocol entirely? Didn't Apple use something called Multipath TCP for mobile connections? Is that vaguely related to mobile IP?

"How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP"

https://www.usenix.org/system/files/conference/nsdi12/nsdi12...

Post reply on HN