Dave Crocker wrote: > On Sat, 06 Nov 2004 09:53:00 +0100, Harald Tveit Alvestrand wrote: > > So the death of IPv4 isn't going to happen with a bang. More like > > a protracted series of whimpers > > One of the great dangers of having a history of success is the way it > blinds us to new ways to fail. > > In the case of IP addressing evolution, the blindness is that our > community presumes that transition to IPv6 is inevitable. A transition away from IPv4 is inevitable. The next stop in the evolutionary path will be determined by available alternatives. The IETF chose IPv6 from the set of proposals on hand. The market will choose something else if the IETF doesn't get serious about focusing all effort in that direction. > Hence, we > have done a very poor job of providing compelling benefits for users > and admins. Which is why I have been after the Applications Area to wake up and recognize that the wasted effort that goes into the random nat traversal schemes is not leaving time to do the necessary work focused on IPv6. > We have a grand promise -- and frankly it often sounds a > lot more like religious fervor -- about eventual benefits, but no > claim of immediate benefit that grabs operations folks by their gut, > driving them to adopt this change. Addressing is plumbing and nobody cares besides the network operator. Applications are the driver that pull technologies along for the ride. Until the apps community decides that continuing to put energy into a dead end technology is a bad idea, we will be stuck on the current path with no compelling driver for change. > > By way of noting one possible scanario that builds on today's reality > and leads down a path that never adopts IPv6, I'll ask: > > What if users turned all leaf networks into private address space, > so > that public IPv4 numbers were needed only at the level of roughly 1 > per public interface? This is happening due to lack of choice. Network operators are finding that their support costs are going up due to app breakage and that it is impossible to offer service guarantees when someone else owns the nat component of the infrastructure. > > This is, of course, the ultimate breakage of the end-to-end addressing > model, but we tend to forget that the model is something rather > esoteric to non-protocol geeks. You say this as if the model were the goal. The goal is simplicity that is a direct output of the model. > > We already must modify the architecture to deal with a much richer > range of border policies than just differential routing. Having it > include partitioned address space is a pretty obvious step, given how > often we already are faced with that reality. Talk about blindness. Has ten years of nat deployment lead to the perception that it is just a minor annoyance that has to be dealt with? Yes we have to deal with rich border policies, but that is not really a new requirement. The U.S. National Labs were implementing whatever the technology of the day allowed 15 years ago, but their policies at the time were not much different than the Dentist office today. Differing policies was the root of most of the inter-agency discussions about topology before the commercialization phase. > > At the least, it means we had better have an end-to-end reference > (identification) construct that is a) separate from IP Address, and b) > works fine over IPv4. To this end, work like Opes and the > architectural aspects of multi6 might be rather more strategic than we > have been acknowledging. Opes has potential for both mitigating some of the harder problems, and/or being a way to trivially subvert system integrity. Lacking a real global trust infrastructure people have piled the trust issue on the routing system through the address token. The simple act of creating alternative endpoint tokens does not automatically move all the trust assumptions. What basis will people have to trust Opes. Multi6 is a worthwhile strategic effort, but the proposals on the table represent an even greater change to the fundamental architecture than simply changing the address length of IPv6. As such it will not really be deployable before 2020, and that is if the array of research efforts can be focused down to a single proposal soon. > > The problem is that we failed to evolve IP in a timely manner and in a > way that was really convenient for real administrators. Some of us knew and discussed going in that it would be a 10 year effort to make a change of this magnitude. Bickering over attempts to tell the operations community how to run their networks has slowed things down, but deployments are happening around the world and given product availability could easily accelerate with the arrival of compelling applications. > Instead we > took the approach that this needed to be done as a major system shift > and that "we would only get one shot at this change", so we also > loaded quite a bit of baggage into the package. And now we try to > characterize the minimal deployment of IPv6 as if it represented > success. One of the biggest problems is using the current measures of IPv4 deployment to gauge IPv6 success. This is more indicative of the IETF's blindness than anything else. Given the current allocation policies the routing system will never see the massive bloat we see today (those policies are likely to change over time though). 'Demand' for blue-plumbing instead of red-plumbing should never happen because the end user of the network should never see it or care. The measure we should be looking toward is application availability and use. To a large degree the app development community is being misled by the IETF's continued efforts at squeezing the last address out of a system we have long since outgrown. > > Or perhaps the real problem was that what has been happening with > NATs, et al, is fine but we that have preferred to tout our idealized > solution and ignored market pragmatics. Market pragmatics of the last few years said the world couldn't wait for the IETF to get its act together and expand the available space. Market pragmatics going forward are more likely to say that nats create an unnecessary expense, both in the cost of the development armies working on traversal hacks and as the source of operational confusion leading to more support calls. Granted I am called in to talk to people already interested in/asking about IPv6, but those are the two points that keep coming up in the market place today. > > Please forgive me for noting that this kind of error is classic among > organizations that have had major successes and, therefore, believe > that their internal intelligence is greater than that of the markets. > A small variation on this error is when it is from the aggregation of > successful companies. The obvious example is OSI. Yes the IETF as a whole is blinded by the success of IPv4. Yes there are participants that want to tell the world how to run their networks. At the same time, there are others who are interested in simply defining the growth path and as Harald said, '... make sure the thing we have defined is well-defined enough to let it work, and then get the hell out of the way.' The plumbing pieces are well defined. The deployment technologies are defined, though several are blocked from publication by those who don't want to 'get out of the way'. The 'internal intelligence' of the collective recent IESG membership has created a road block for deployment technologies that don't fit their model of how people should be running networks. The real pieces that are lacking in the IETF output are in the application space. As Brian noted, work is going on now to address the market perceptions about what nat does and how to accomplish the same tasks in IPv6 without nat. This is nowhere near enough to help the world of application developers understand how to create-in and/or port-to an IPv6 environment. As Harald also said, 'Frankly, folks, IPv4 is what IBM used to call "functionally stabilized".' This means there is no reason for the IETF to focus any effort on standardizing new functionality around it. This was the basis for my comment about closing down IPv4 related discussions during his term. Yes there will be new IPv4 based product and service developments in the market for years to come. That is both due to training of the existing developers and operators as well as the fundamental need to leverage the vast existing environment. Those product and service developers do not need any new output from the IETF to create their wares. At the same time they will need output from somewhere to move beyond the limitations of that existing environment. The IETF has a choice, it can either make its earlier IPv6 choice the default for all current work, or it can become irrelevant when someone else provides a replacement for the 'past its prime' workhorse of IPv4. This is simple market pragmatics, no religion required. Tony _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf