141–150 of 199 posts
That is a beautifully-written article. The IEEE hardware and IETF software guys have been busy adding complexity to the networks, with so many legacy protocols (when everyone just uses TCP/IP) and extra ports (when everything happens on port 80 - seriously, even email is now on cloud services). I can't get LTE because of political problems. So I just gave up trying to be online, and started caching everything possibl…
Earlier quoted context omitted.
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 c…
Incorrect, you might want to read about TLS SNI (Thought exercise; the server has to pass your packets to the correct vhost before decryption).
You might want to Google dTLS (TLS over UDP) and then read some of the dialogue about why it's impractical on the public internet.
Consider further that by moving your presentation layer logic into the network layer, every time you want to introduce a new cipher you'll need to upgrade every network device on the internet. Think how bad the export-grade crypto problem has been, then multiply by the momentum of Tier-1 ISP install base. Instead of making the network less important, you're handcuffing yourself to Verizon.
This 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…
This 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…
"The problem with ethernet addresses is they're assigned sequentially at the factory, so they can't be hierarchical. That means the "bridging table" is not as nice as a modern IP routing table, which can talk about the route for a whole subnet at a time."
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.
There is a straight-forward mapping of the IPv4 address space into IPv6 (you can do ping6 "::ffff:127.0.0.1"), and for new development that is also by far the easiest way to support both protocols: the application does everything in IPv6, and without writing a single line of code, the OS takes care of transparently using IPv4 when needed. There is no mapping back from IPv6 to IPv4 (so IPv6 is backwards compatible, bu…
Hence IPv6 is definitely not backward compatible.
This 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…
They are supposed to be unique, but in the real world they are not.
This 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…
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.
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.
Earlier 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.
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…
Chesterton's Fence neatly saves the utterly pointless fences in our lives, regardless of the damage they can cause.