Dan, Brian: A bit of historical information and some comments on the current issue included below.
AEB On Tue, 11 Feb 2003, Dan Lanciani wrote: > Brian E Carpenter <[EMAIL PROTECTED]> wrote: > > |Dan Lanciani wrote: > |... > |> |I wasn't around then, but from what I have been told and read I think > |> |everyone was very aware of the scaling issues. But decided to put them > |> |forward and buy time. > |> > |> Well, I was around and I don't recall any major concern. > | > |This is hard to reconcile with some of the words in RFC 1380, > |or what I remember when I first arrived in late 1992. > I _was_ around, and I _do_ remember these events. Here is the best of my recollection. About 1992 the community of user-network admininstrators (of which I was then a member) began to show considerable uneasiness about a looming shortage of IPv4 registered address space. Within two years class B address allocations were becoming very scarce, and registered class Bs were becoming increasingly hard to get. In 1996, a company for which I was acting as network administrator _gave_ one of their registered Class B allocations to a local residential community with had been unable to obtain sufficient registered space via the normal applications process! Many networks converted to VLSM, and others began to use PNN space, in an attempt to stave off the inevitable restrictions on growth which the scarcity of registered IPv4 space was expected (not inaccurately) to impose. The later introduction of CIDR and provider-based addressing, as you well know, enabled the vast growth of the "online" services (AOL and entities of that ilk), but at the cost of great operational difficulties for privately-operated networks which needed to expand. Use of PNN and NAT grew explosively. In summary: yes, there was knowledge and concern over the IPv4 address scarcity issues as early as 1992. There were some administrative (as distinguished from technical) managers who chose to play ostrich (you know what that bird exposes when it sticks its head in the sand), but the user technical community was aware of, and alarmed about, the issue. Subsequent experience with provider-based addressing has convinced almost all administrative managers of privately-operated networks, and most technical managers and network administrators, that renumbering is to be avoided at any cost short of summary hanging. Absent the ready availability of provider-independent, globally routable address space, I suspect that most of my clients will continue to require the use of non-globally-routable addressing in their internal networks, with NAT and application-level gateways used where public-network access cannot be avoided. As indicated by the general sentiment in this WG, the conditions described immediately above are, to put it politely, far from desirable. This account puts me in mind of a quote from Mark Twain (Sam Clemens),to wit: "a cat, once he has sat on a hot stove lid, will not do so again; but he'll never sit on a cold one either". The user-network managers are unlikely to change their opinion in the foreseeable future, engineering advice to the contrary notwithstanding. > IMHO, by the time 1380 was published in 1992, RFCs were not quite the > reflection of community feeling that they had once been. RFC1380 was an > attempt to highlight the problem and encourage the concern as much as it was > an expression of that concern. Note that while 1380 does brief lip service to > other possible solutions (including a distributed one!), it quickly concludes > without proof that aggregation must be part of any long-term solution. At > least that's the most obvious reading of a sentence that isn't quite English... > > |My recollection > |is of a consensus to buy time with CIDR. > This accords with my memory: CIDR was seen as a stopgap, to provide, at best, temporary relief until IPNG could be got into service. CIDR and its familiar, aggregation, were considered necessary as distinguished from desirable. Provider-based addressing was seen by most user-network administrators as a definite evil, and there was considerable consternation when the PA model was specified as the default allocation scheme for IPv6. So much for the historical context from the standpoint of end-user-network administrators. We are now (as pointed out at some length by others below) reaping the consequences of a decision to use hierarchical PA as a tool to achive route aggregation: the situation is about as appetizing as attempting to swallow a porcupine wrong-end-to. Based on experience with my clients, I strongly suspect that end-user networks will not embrace IPv6 enthusiastically unless registered, globally routable PI space is readily available. Independent of the technical merits of routing aggregation, PA addressing, with its history of lack of portability and the renumbering overhead, will be seen as a probibitively disruptive for almost all end-user-network administrative managers, and for most technical managers and network administrators. > There was a consensus to use provider-based hierarchical allocation as a > temporary fix for a projected problem. Unfortunately, there was some confusion > about how much time we were trying to buy and exactly what we were buying that > time for. > > Initially the plan was presented as just that: hierarchical *allocation* by > providers to end users. The addresses so allocated were to be portable and > were to belong to the end user. The theory was that this would slow routing > table growth, but would ultimately put us right back where we started once > enough people changed providers and took their addresses with them. This > scheme was perfectly consistent with the notion of "buying time" and it was > not going to be a serious burden for end users. > [...] > Dan Lanciani > ddl@danlan.*com That's my $.02 worth. AEB -- Alan E. Beard <[EMAIL PROTECTED]> AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
