[deleted]
The world in which IPv6 was a good design
151–160 of 199 posts
Re: The world in which IPv6 was a good design
#152Earlier quoted context omitted.
> This is completely wrong, it's not pointless. Pretty reliable rule of software is: if you think it's pointless you probably don't understand it well enough.
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.
Re: The world in which IPv6 was a good design
#153This was a very informative article for me, but there was one thing I didn't understand. At the end he made the case that mobile routing needed essentially two layers: a fixed per-device (or per session) identifier, and then a separate routing-layer address that could change as a device moved. QUIC has session identifiers, and that's great and could solve the problem. But earlier in that very article, he already poin…
In theory we can use MAC addresses, but there are problems: 0) Privacy: You don't want all traffic to be labeled with your hardware ID. 1) Flatness: MACs are essentially random, and a router would need a huge table to keep track of who's where. IP (v4/v6) assigns addresses hierarchically, making routing tables manageable.
The idea would be to use IP addresses for all levels of routing, and MAC addresses only on the endpoints to identify the connection. So routing actually becomes simpler. However, you have a good point about privacy. One of the other commenters also mentioned non-unique MACs.
Another point against using MACs which I want to point out is that they don't make much sense if you have a service running on multiple hosts. I mean, you could introduce "virtual MACs", but it seems better to keep the idea of "service ID" separate from "device ID". Session IDs solve the multiple hosts problem too, by completely avoiding it.
Re: The world in which IPv6 was a good design
#154>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…
>"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.
No its not. The source host putting a DHCP discover request on the wire doesn't have a real IP until the complete Discovery, Offer, Request and Ack sequence is completed which is two round trips during which time the source IP of the client is still 0.0.0.0. This is why DHCP uses raw sockets.
See: https://en.wikiversity.org/wiki/Wireshark/DHCP
>"DHCP is very much an IP protocol (see DHCP relay for how it transits IP networks)."
I would say that DHCP is very much a layer 7 protocol, as it deals with leases and renewals etc. It uses IP yes because it uses UDP and UDP must use IP but I don't think that makes it an IP protocol.
See: http://www.tcpipguide.com/free/t_ApplicationLayerLayer7.htm
Re: The world in which IPv6 was a good design
#155What 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…
mosh layers this sort of thing over UDP, to provide client roaming capability.
Re: The world in which IPv6 was a good design
#156This 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.
Re: The world in which IPv6 was a good design
#157What 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…
Check out: https://named-data.net/project/
Re: The world in which IPv6 was a good design
#158Earlier quoted context omitted.
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.
Maybe it's early and I've not drank enough coffee yet, but what benefit would this provide? You'll be in effect doubling the DNS lookups needed to connect to a website adding latency to time to first byte, with seemingly zero benefit.
As I pointed out at https://news.ycombinator.com/item?id=14721416 , the claim of "doubling the DNS lookups" simply does not hold water if actually analysed.
Re: The world in which IPv6 was a good design
#159Earlier quoted context omitted.
This seems really complicated. Is ZeroTier closer to an cjdns- / i2p-style system, or is it closer to CurveCP/MinimaLT/QUIC? (QUIC being the odd one out of the trio as it grafts on some awful HTTP semantics, but that's Google for you.)
> QUIC being the odd one out of the trio as it grafts on some awful HTTP semantics, but that's Google for you. What specifically do you mean by that, and are you sure that it still applies to the IETF version?
There are a number of statements like "QUIC is functionally equivalent to TCP+TLS+HTTP/2" in the "QUIC wire specification" and other documents, and this agrees with what I remember seeing in the source in the Chromium repo when I last looked.
I've not read about the IETF version; I'll look into it.
Re: The world in which IPv6 was a good design
#160Earlier quoted context omitted.
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.
Maybe it's early and I've not drank enough coffee yet, but what benefit would this provide? You'll be in effect doubling the DNS lookups needed to connect to a website adding latency to time to first byte, with seemingly zero benefit.
The main benefit would be the ability to offer public Internet-facing services through a NAT, even a carrier-grade NAT that lumps multiple ISP customers behind a single IP address. (You would need some kind of cooperation from the NAT to be able to allow incoming connections on a port range.)
JdeBP's post provides a good answer about the SRV records. The short version is a single DNS packet can contain both A/AAAA and SRV responses.