Earlier quoted context omitted.
The main issue with IPv6 adoption is people who didn't learn IPv4 before NAT, and want to use the hammer (IPv4 NAT) for everything.
A hammer working fine today, that you own, is better than a machine tool tomorrow, that you'll have to pay.
Protocol Wars
71–80 of 121 posts
Re: Protocol Wars
#72This was still raging when I was a student. From my recollection I _heard_ a lot more about OSI, but everything I used had something proprietary (e.g. NetWare, Token Ring) or TCP/IP. The people supporting TCP/IP had a head start and out-executed the OSI committees and it wasn’t even funny.
Yeah. Top-down vs. agile. Cathedral vs. bazaar. "The right thing" vs "worse is better". And, as you said, the agile/bazaar/worse-is-better camp totally out-executed the top-down/cathedral/do-it-right approach, to the point that OSI is only a theoretical model at this point, and TCP/IP is running in everything from supercomputers to washing machines. Another one of the "well-done in theory, but left in the dust by rea…
Re: Protocol Wars
#73This was still raging when I was a student. From my recollection I _heard_ a lot more about OSI, but everything I used had something proprietary (e.g. NetWare, Token Ring) or TCP/IP. The people supporting TCP/IP had a head start and out-executed the OSI committees and it wasn’t even funny.
Then the next (?) year there was access to the "PAD" (Packet Assembler Disassembler) to JANET, from which one could issue a command to connect to an X.25 address. I still remember the number of NSFNet relay, 00004001018057 [1], which in turn allowed you to telnet to other internet services. I think I logged into Nyx and a few other BBS-like things.
Then I did an industry year at ICL, a British computer company long-since engulfed by Fujitsu, where they were also X.25 focused for big networks and Novell Netware focused for small networks - but the web was starting to be a big deal and I couldn't get anyone to listen. I have an anecdote about downloading the SLS Linux distro via an archive re-mailer that I won't bore you with right now :)
Then, in my final year back at the university, the web seemed to explode and the X.25 stuff had more or less disappeared.
In retrospect it's amazing how quickly this changeover happened, even if it had been bulbbing away in the background for a long long time. From my perspective the WWW looked like the catalyst that pushed everything in favour of TCP/IP.
[1] If I remember rightly, the adjacent address 00004001018056 was another Vax somewhere that hosted a bunch of LaTeX stuff?
Re: Protocol Wars
#74Earlier quoted context omitted.
that's never going to be a seamless transition. the fact the transition happens automatically is a marvel in itself
> that's never going to be a seamless transition. Why not? It is not obvious to me why a seamless transition is impossible? Isn't the whole point of TCP that individual packets can take different paths over different networks and when they reach the destination they can be sequenced? Why should changing the network disrupt the individual packets from traveling independently?
- Find the new address; i.e. Cell provider vs. Residential/Business ISP - Associate the new address with the same flow - Duplicate packets and reassemble them, or change to "better" path interface.
Re: Protocol Wars
#75> During a dispute within the Internet community, Vint Cerf performed a striptease in a three-piece suit at the 1992 Internet Engineering Task Force (IETF) meeting, revealing a T-shirt emblazoned with "IP on Everything"; according to Cerf, his intention was to reiterate that a goal of the Internet Architecture Board was to run IP on every underlying transmission medium.
Re: Protocol Wars
#76Earlier quoted context omitted.
> I wish we could start over and redesign everything ... I wish we all could learn that "because it works now" is a valid reason to resist change, and that assuring back compatibility is a condicio sine qua non for every change that we want adopted by people at large.
"Because it works now" is a perfectly good reason, I was more talking about a hypothetical "wave a wand and change all devices overnight" scenario. I think an IPv8(Apparently we skip odd numbers) could be a real practical thing one day though, because a lot of things really do with quite work that well. The classic "it's always DNS" meme seems to be very real, tying TLS to domains instead of IPs impedes anything on L…
TLS doesn't care what's in the certs, that's an application concern. IP addresses work fine in x.509 certs, but are discouraged because of difficulty of validating that control of the IP will continue through the certificate validity period. But this wouldn't much help for your LAN use case, assuing you're using RFC1918 addresses, because no one can prove control of those, so no publicly trusted CA should issue certs for them. Same thing if you use ipv6 link local, although I don't know too many people typing those addresses, mostly people want to type in a domain name, and if you make a real one work (which is doable), you can use a real cert; if not, not.
> IPv6 has too much inconsistency in how many bits are allocated to customers, and would be much saner with a more structured ISP/Region/Subnet/DeviceChosenIDThatIsTheSameEvenIfYouChangeISPs scheme so every ISP got the same number of bits.
DeviceChosenID that is the same everywhere is kind of a huge privacy thing that we already had and mostly rejected. Giving every ISP the same number of bits is silly anyway; Comcast needs more bits than [ISP that only serves California], and heirachical addressing is lovely for humans, but not necessarily a great way to manage networks; each regional portion of the network is going to end up doing its own BGP anyway, at which point, the heirarchy doesn't make a huge difference.
> Some level of onion routing could probably just be built right into IP itself, there's not much reason an ISP or even the local wifi router needs to know the destination I'm sending a packet to, if there's a fixed heirarchal structure, it just needs to know the recipients ISP, and the rest could potentially be encrypted at the cost of some negotiation setup complexity.
Source routing exists in RFCs but was quickly dropped. There's a lot of security reasons, but also it just doesn't work that well. The destination is needed to make the best routing decisions.
Say you're in Chicago, sending to me near Seattle, and our ISPs peer in Virginia and Los Angeles (which is a bit contrived, but eh). If you send to the nearest peering, traffic will go east to Virginia, then west to Seattle. If you look up by destination, you'll more likely go west to LA, then north to Seattle and total distance will be much less.
Re: Protocol Wars
#77I wish we could start over and redesign everything from Ethernet up to TLS with the lessons we now understand. So many layers could be merged, security could be so much easier, IP addressing hassles could be unnecessary. But all the stuff that seems obvious now couldn't have been learned without the decades of kind of terrible hackery that is OSI and the associated awful stuff like DNS. I'm not sure what the moral of…
Re: Protocol Wars
#78This was still raging when I was a student. From my recollection I _heard_ a lot more about OSI, but everything I used had something proprietary (e.g. NetWare, Token Ring) or TCP/IP. The people supporting TCP/IP had a head start and out-executed the OSI committees and it wasn’t even funny.
Then people who went to school in the late 80s took that to $WORK in the early 90s, and by the mid-90s everything that wasn't TCP/IP had died. Novell's IPX, for example, was a thing still in the mid-90s, but a dying thing. Winsock for Windows 95 was the last thing that was needed to make TCP/IP rule -- after that there was just no way to do anything but TCP/IP.
It was a matter of network effects.
Re: Protocol Wars
#79Earlier quoted context omitted.
The fact that it takes so long to transition to IPv6 and like many other obstruction to technological/social progress are economic and business gain for a certain small group of people and organisations.
People wanted to change bitfield with version from 4 to 6 and increase amount of bytes in IP address filed. Simple KISS. Instead of that we got fragile, backward incompatible, unnecessarily complex, jack of all trades protocol. And people are surprised that even after decades since the release of IPv6, it is being avoided like a plague.
Re: Protocol Wars
#80In the mid-1980s, I took the OSI course. That's a bunch of time I'll never get back. That was nothing, though, compared to the X.400 course...