On Tue, 2011-03-08 at 07:37 -0500, Steven Bellovin wrote:
...well, kind of. What you don't mention is that it was thought to be ugly and rejected solely on the aesthetic grounds. Which is somewhat different from being rejected because it cannot work.
No. It was rejected because routers tended to melt down into quivering puddles of silicon from seeing many packets with IP options set -- a fast trip to the slow path.
Let me get it right... an important factor in the architectural decision was that the current OFRV implementation of a router was buggy-by-design? Worse, when having a choice between something which already worked (slow as it were - the IPv4 options) and something which didn't exist at all (the new L3 frame format) the chosen one was the thing which didn't exist. Any wonder it took so long to get IPv6 into any shape resembling working?
It also requires just as many changes to applications and DNS content, and about as large an addressing plan change as v6. There were more reasons, but they escape me at the moment.
Not really. DNS change is trivial; and if 64-bit extended IPv4 address was choosen (instead of a new address family) 80% applications would only needed to be recompiled with a different header file having long long instead of int in s_addr. Most of the rest would only need a change in a data type and maybe in custom address-to-string formats. Compare that with try-one-address family and if failed try another logic which you need to build into every app with the dual-stack approach. Do you remember the mighty trouble with changing from 32-bit file sizes to 64-bit size_t in Linux? No? That's the point. Valdis.Kletnieks@vt.edu wrote:
Steve, you of all people should remember the other big reason why: pathalias tended to do Very Bad Things like violating the Principle of Least Surprise
As the guy who implemented the country-wide domain name e-mail router over UUCP, I remember this issue pretty well. In any case, it is not applicable if you structure 32-bit address spaces into a tree. Which maps very nicely onto the real-life Internet topology. Steven Bellovin wrote:
And then some other dim bulb will connect one of those 5 layers to the outside world...
A dim bulb has infinite (and often much subtler) ways of screwing routing in his employer's network. Protecting against idiots is the weakest argument I ever heard for architectural design. (Now, I don't deny value of designing UIs and implementation logic in a way which helps people to avoid mistakes... how could I, having been doing GPS Z to SQL just a few hours ago, in IMC:) So. You pretty much confirmed my original contention that the choice was made not because of technical merits of the LSRR or IPv4 extended address option but merely because people wanted to build beautifully perfect Network Two - at the expense of compatibility and ease of transition. Well, I think IPv4 will outlive IPv6 for precisely this reason. The real-life users don't care about what's under the hood - but they do care that the stuff they used to have working will keep working. And the real-life net admins would do whatever it takes to keep the users happy - even if it is ugly as hell. --vadim