Posted by compiler-guy 2 days ago
Just the nicest guy you could imagine. He took the note-takers job during our breakouts, had beers with us after the session, and asked really good questions and never asserted anything the whole time.
What a legend.
For all that we complain, it’s still the most amazing thing ever.
However I never forget my surprise, Idly flicking through TV one evening and coming across Earth Final Conflict - and there was Vint in a fairly substantial role
It’s like two lifetimes in tech years. I remember that summer Google Earth was launched, we were a year removed from the Gmail launch, and I worked on shipping the first Summer of Code.
(I guess a decade later, was IPv6 important? Still not sure about that one. But it seemed important at the time.)
Just know that my mentor was hand-holding the hiring process which basically prided itself on false negatives and still probably does.
And they were still in the era where's they'd just keep interviewing you until they "got enough signal" so people would be back 3 and 4 times.
Legends
Disc: Former Googler, Cloud Networking.
Similar ish to an influencer
Maybe having multiple streams within a single connection, like QUIC does, would have been a better choice. Also being able to demarcate message boundaries within the protocol itself, perhaps, instead of it being a simple byte stream.
1. It would have 128-bit addresses. 2. It would have end-to-end encryption (or was it authentication, I forget).
IPv6 was supposed to fix both of these, with IPsec mandatory, but the latter demand sort of faded out into obscurity. We ended up basically solving encryption by pushing everything into TLS anyway, which I guess solved much of the same problems although at a very different layer.
The "solving" of encryption with TLS should not be celebrated.
Everything needs to go over TLS/HTTP-443 because of middleware boxes basically blocking everything else by default in many cases, and so application/protocol designs have to shoehorn / kludge everything into a round hole even if it's a square peg.
Certainly I'd want everything to have encryption at the higher layers (OSI 5-7), but having opportunistic encryption at IP (OSI 3) would also be great because snoopers could tell that two nodes are communicating but not how / what: RTSP? Torrent? Mindcraft? PvP2 game? If every node could (say) do an IKEv2 negotiation with every other node have IP-level traffic wrapped in IPsec that would help with traffic analysis.
I always wonder if the internet is thesurvivor of the networking cambrian explosion, with a slight roll of the dice making another candidate the winner.
Yes and no. The current internet arguably does not work without a browser and a TLS stack anyway, neither of which is easily implementable (e.g. number of practically usable rendering engines is in the single digits). I mean, I can piece together an IP packet, too, but there's not that many usable services reachable that way.
Or there is too much inertia for IPv8 to overcome to become a truly backwards compatible extension / superset of IPv4?
Part of the reasons for the slow adoption of IPv6 was that it was never designed to be backwards compatible unlike IPv8.
Anyone can publish an IETF draft document, it doesn't mean it's a serious proposal under consideration or will ever actually be implemented.
IPv8 solves precisely zero of the problems that is causing a 'slow' roll out of IPv6 / replacement of IPv4:
"""
So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately:
You have to change the version number.
You have to add new code to handle the new version.
Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So,
You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions:
(3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses between the old and new protocols.
[…]
Incidentally, "IPv8" proponents often ask why IPv6 didn't simply stick some extra bits on the front of IPv4 addresses, instead of inventing a whole new format. Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The related "IPv4-Mapped IPv6 address" format is still valid and has a role in the POSIX socket API. Mappings of this kind also figured in the moderately successful coexistence technologies known as 6to4 [RFC3056, RFC3068] and Teredo [RFC4380], which have now been overtaken by events.
"""
* https://github.com/becarpenter/book6/blob/main/01.%20Introdu...
* Interview with author of article: https://www.youtube.com/watch?v=W3jkZ1Ulz-s
I'm always fascinated by how many people think IPv6 adoption would have gone lightning-fast if we just used This One Weird Trick, where said trick has actually been tried and didn't help. They usually refuse to back down even after you tell them so.
This thinking can be seen in the allocation of network blocks. Mercedes Benz getting 53.0.0.0/8 is just a "we have more addresses than we ever need."
If somebody had imagined "yeah, let's give an address to each of our vehicles" they would have realized the space running out.
In a sense, he did. Take a look at RFC 4838.