Steve Deering (deering@parc.xerox.com)
Sun, 15 May 1994 21:19:53 PDT

I think what's going on here is a fundamental disagreement over whether we need a new *architecture* for the internet layer, or a new *instantiation* of the current architecture.

By "the current architecture", I am referring to the datagram/connectionless internet design, which uses a common internet protocol layered on top of the services offered by a variety of networks, uses hop-by-hop routing based on globally-unique, hierarchical addresses that are carried in every packet, and offers a best-efforts delivery service for variable-length packets, up to a few hundred to a few thousand bytes in length. The architects of the current architecture were the people who designed IP and Pup. Some other instantiations of that architecture, besides IP and Pup, are XNS's internet protocol and its descendant IPX, Appletalk, and CLNP. Examples of protocols that are *not* instantiations of the current architecture are X.25, ISDN, Frame Replay, and ATM. (And let's not debate whether those all belong to the same architecture -- "connection-oriented" -- or to different architectures -- "reliable, connection-oriented", "cell-based, connection- oriented", etc.)

Now if you believe that we need a new architecture, then Noel's comments make perfect sense. Coming up with a new architecture is a major undertaking. It should entail deep re-examination of every decision made in previous architectures, and going back to first principles to decide what services, functions, and concrete realizations should be included in the new architecture. It cannot be rushed or held to any artificial deadline. We should not worry about external perceptions that we are "taking too long", because the job of fully defining a new architecture should be recognized by everyone as one that takes long and careful thought, prototyping, and testing.

On the other hand, if you believe that we need a new instantiation of the current architecture, then it is reasonable to ask "why is it taking so long?" The current architecture is well-understood. We have lots of previous experience to draw on, both in IPv4 and in other instantiations of the same architecture. It should just be a matter of competent engineering. If the Internet *Engineering* Task Force cannot manage that task, then it might as well be disbanded, and the job taken up by Novell or cisco or any other bright group of network engineers who will just get the job done.

I do not believe the Internet needs a new internet-layer architecture. The current architecture has proven remarkably flexible and robust, due to its minimal requirements from lower layers, its minimal service "promises" to upper layers, and its simple, stateless, datagram routing and forwarding model. As a result, it has survived the introduction of many new lower-layer technologies and many new applications (including real-time applications). Its functionality has been upgraded continuously (e.g., new routing protocols, subnets and CIDR, multicast, MTU discovery, DHCP, ...) *without* changing the architecture. As Yakov has pointed out, almost every feature, function, or capability that has been suggested as desirable for IPng can be provided in IPv4 (an instance of the current architecture), except a bigger address space. For example, the current architecture can support policy-based routing (SDRP), mobility (Mobile IP), auto-configuration (DHCP), and flows (CSZ/RSVP). Acknowledging that kludges are in the eye of the beholder, I do not view the implementation of those functions in IPv4 to be kludges that are corrupting the purity of the original architecture (and therefore evidence that a new architecture is needed), but rather I see the fact that they can be accommodated within the current architecture as validation of the flexibility and potential longevity of that architecture. Granted, the implementation of some of those functions might not be as efficient as they would be in a different protocol than IPv4, but in most cases that's simply a problem with the *instantiation* of the architecture, not the architecture itself. For example, new services or functions that take advantage of the *architected-in* extensibility mechanism of IPv4 -- IP header options -- suffer from the particular instantiation of that mechanism in IPv4 (small bound on option length, need for all routers to parse all options).

I *do* believe the Internet needs a new instantiation of the current architecture -- an IPng -- in order to increase the address space, to allow for both more hierarchy and more nodes (i.e., the original ROAD problems). Given the long time it will take to deploy, the unpredictability of the growth of the Internet, and the exploitation of IPv4's perceived limited lifetime by those who wish the Internet to die, I think it is important to come to agreement on IPng as soon as possible. Since I do not see this as a grand architectural undertaking (though it will certainly be a grand implementation, deployment, and transition undertaking), and I do not see that we need a new architecture so desperately that we should risk the demise of the Internet waiting for one to be defined, tested, and agreed upon, I see no reason not to choose an IPng in July. I am not particularly worried about IPng having to be replaced by an IPngng in the near future. (I'm more worried that, if we don't get IPng out there soon, we'll end up with NAT boxes everywhere, which will *break* the current architecture.) If we *engineer* (not *architect*) IPng well, there's a fair chance that it will serve as the final refinement of the current architecture, perhaps serving as a transition target for other instantiations of the architecture, such as IPX, Appletalk, and CLNP. Whatever comes next -- if anything comes next -- will be a completely different architecture, not an IP-anything, and it will be deployed, as ATM is being deployed, oblivious to the internet architecture.

When Noel accuses SIP (I can't speak for the other proposals) as lacking its own architectural philosophy, or of being "only another header design", he is exactly right. The architects for SIP were those who designed the datagram internet model (Cerf, Postel, Shoch, et. al.). SIP is simply a new instantiation or engineering of their architecture, taking into account some of the lessons learned from previous instantiations (e.g., the value of good alignment, the value of fixed-length, relatively compact addresses, the need for more efficient and less length-bounded option encoding, the inadvisability of internet-layer fragmentation, etc.) It's "only another header design", because the only problem with IPv4 that makes it worthwhile to undertake the pain of deploying a new version is a header design problem: its address fields are too small to accommodate the projected growth of the Internet.

My contention that IPng is *rightly* "just header design" does *not* mean that I think header design is unimportant. True, it is not nearly as important as architecture, but in my opinion, we already have an excellent architecture with lots of life left in it -- if it *is* going to last a long time, we want to have a reasonably good instantiation of it, based on our experience with it so far. That's one of the reasons I was opposed to the IAB's Kobe decree that CLNP be IPng -- I thought (and still think) that CLNP is a poor instantiation of the architecture, and I believed that the Internet community could design something better. We have now had the time to try to do that, and it is time for the community to judge those attempts and make a decision. If the choice is still CLNP, so be it.

I should point out that I think Pip was more than "just header design"; it also embodied significant new architecture, and those parts of SIPP that are derived from Pip (generalized use of "source routing" for hierarchical addressing, provider-selection, mobility, address-changing, etc.) are certainly not based on the earlier instances of the internet architecture. And I should also admit that Paul and I disagree sometimes about whether or not those new architectural features should be considered as optional functionality or part of the base design. Certainly, the introduction of a new version of IP gives us a rare chance to introduce promising new architectural features, but my conservative design nature would like to avoid risking the success of the design on the success of those new features. The same is true of features like the Traffic Class and Flow ID fields in the SIPP header. Based on my own architectural work (wearing a different hat than my IPng Engineer's hat) and that of more architectural thinkers with whom I have frequent contact (Zhang, Shenker, Clark, Jacobson, Estrin, Huitema, and others), I have incorporated features into SIPP that seem likely to satisfy their/our vision of how the internet architecture might evolve. However, I have been careful to make those features optional. If they don't pan out (like IPv4 TOS didn't pan out), it won't hurt anything (the space they occupy in the header would have been spent anyway, for alignment reasons). They are basically just mechanisms to improve efficiency of forwarding and/or link utilization -- if they don't work, then we can fall back on our traditional solution: more bandwidth and faster routers.

One thing we have learned is that the current architecture does not cleanly support migration to new versions of the internet-layer protocol. This is not too surprising, given that a fundamental feature of the architecture is the use of a single, universal internet-layer protocol. I hope that the current exploration of transition strategies (IPAE, dual-stack, etc.) will lead to architectural insights for the future, whether for transitioning to an IPngng if necessary, or for transitioning other internet protocols to IPng.

To bring this rambling message to a close, I suggest that we suspend arguments over the requirements for IPng (and self-flagellation over our mistakes of the past, whatever we perceive them to be) until we have agreed on the meta-requirement: must IPng embody a new internet architecture, or can it simply be a re-engineering of IPv4? If you believe that we need a new architecture, do you think we can do a proper job of designing, testing, agreeing on, and deploying it before the market decides to give up on IPv4 and migrate to a better version of the current architecture (e.g., a new version of IPX) or an alternative architecture (e.g., ATM)?

Steve

Date sent: Wed, 12 Nov 1997 03:45:08 -0800
To: bound@zk3.dec.com
From: Fred Baker
Subject: (IPng 4787) Re: Hello Fred - IPv6 is IPng
Copies to: ipng@sunroof.Eng.Sun.COM
At 7:39 PM -0500 11/10/97, bound@zk3.dec.com wrote:

>Sitting here in this WG I am unclear that you as IETF Chair understand
>all the IPng issues per RFC 1752. None of what you mention as IETF
>Chair (Jim Duffy is quoting you in your role not as individual) fixes
>the problems with IPv4 for many of the issues in 1752 IMO. But I am
>more concerned about your statement of "something better" IPv6 is
>being tracked for a Global Internet Standard.

There are several things that concern me here, some of which are in your note and some of which are in his article.

I would describe his article as a particularly poor bit of reporting. I spoke for some 45 minutes on the subject of the trends that I personally (not the IETF corporately) see as important in the Internet for the next few years, which have to do with putting an economic underpinning under the net in the form of what the Integrated Services folks call the Differentiated Services model. This basically calls for and enables the Internet to provide best effort services with a business model more like a telco's. Note that the primary subject of the talk, what I discussed for at least 30 out of those 45 minutes, is not mentioned in his report. That is, at best, incomplete reporting.

When the talk was over, I was asked a few questions, one of which was "you didn't mention IP6 - why not?" The answer was simple enough - I didn't mention IP4 either. IP4 has facilities that can be used to deploy the Differentiated Services model, and as IP4 is in place today and will be predominant for the foreseeable future (which I stated during that Q&A to be "until we all walk into the hall to get coffee", but which I think will probably be until after both of us retire), is the first vehicle that will be used to deploy this. IP6, last we discussed this subject on this mailing list, was in danger of having its priority field removed and has no TOS flags, and therefore doesn't presently have the facilities necessary to deploy Van Jacobsen's "Pre-emptive Service" and was at least at one point in time considering being unable to deploy Clark's "Assured Service". So IP6 may or may not be able to support the facilities that I see as critical to the Internet over the coming years. That remains to be seen.

I did not say that something else was on the standards track for IPng. What I said - and he got parts of the quote right - was that the initial urgency of deploying an IPng has been mitigated by developments such as CIDR, NATs, DHCP, and private address spaces. No comment on the architectural aspects of that - frankly, there are serious architectural problems with NATs, not the least of which is a single point of failure, the loss of which forces an end to end restart of TCP sessions. But what we thought at one time we might be forced to deploy as early as 1993 looks like (according to Frank Solenski's Address Usage statistics the last time I saw them) it might not be needed for as much as another decade. And in that time - well, maybe your crystal ball is clearer than mine, but my crystal ball doesn't preclude somebody having a better idea than IP6 as presently formulated. If we do indeed have a better idea in the meantime, I said, we would deploy said better idea.

If you want my concerns with IP6, I think you are already in receipt of them. But I'll give you a little list.

First, as I say, I think scalable differentiated services of some form are mission critical, and I think that this does not imply RSVP or any other per-flow state negotiation over the backbone. Per-flow state negotiation using protocols such as RSVP is important in unregulated portions of the net such as corporate networks, but when the data enters a service provider's transit network, such things will be managed by contract, and therefore by message attributes, rather than by maintenance of per-flow state. Question of applicability space.

Second, I think the flow label in IP6 is poorly designed. One needs something akin to what it is now fashionable to call "label switching" to do special-flow QoS in a scalable fashion. We can do it at the IP layer or at a layer one below, it really doesn't matter to me.

Third, the address size discriminates against low delay applications on low speed lines. Say it any way you want to, I don't care, but take this example and think about it. On an ISDN basic rate line (128 KBPS in two B channels), I can place two standard telephone calls using voice technology, and perhaps three VoIP calls if I use IP4, or two voice calls plus miscellaneous best effort traffic such as web and email exchanges. VoIP uses a compression technique that sends standard voice at about 40 messages a second comprising an 8-16 KHz voice bit stream. The difference between an IP4 and an IP6 header is an additional 20 bytes (if memory serves), which means that using IP6, I will get two voice calls on that same line, no more. The stated ROAD requirement was for an address that would identify 10^12 networks and 10^15 hosts, which is achievable with a 64 bit address at a usage density of only one address in 16,000 - where the moaning I hear today is that folks (deplorably) use about one address in one hundred. I'm sorry, nobody has ever given me an explanation for the bloated 128 bit fixed size address that I could correlate to the requirements the address had to meet, and I see the address as hurting interactive, transaction, and real time applications on the most widely deployed links in the world - T-1 and below.

From my perspective, if a typical network administrator can do all of his work using either IP4 or IP6, and he gets better service (higher throughput and lower delay on the delay-sensitive applications that his users form their impressions of his network from) on IP4 using economical lines, while IP6 pushes him toward higher cost lines, I should expect the typical network administrator is going to delay introduction of IP6 as long as possible. I don't see how he could otherwise defend his job. And until there is someone else using IP6 that he *has* to use IP6 to talk to, and he *has* to talk with him, I don't see any community of interest that he serves requesting IP6 services by name. The laws of the marketplace militate for "IP4 with band-aids" over IP6 with a vengeance. Note that I am not speaking, in that, as a detractor of IP6. I am speaking as a practical person with a finite wallet about how people like me behave in the marketplace, whether that marketplace is the grocery store, the hardware store, the corporate budget cycle, or the Internet.

So much for the issues in the article. Now for my issues with your note.

Jim, you live in a state whose motto is "live free or die". You live with that fundamental ethic in your daily life, and you display that ethic in the messages you send to the net and your interactions in IETF meetings. Do you have a problem with other people also living by that ethic? When I am asked to speak about the issues that I see (from my vantage point as IETF chair) as critical trends over the next few years, where does it say that I must reflect your marketing viewpoint? Where does it say that I must mention your favorite work item, or that if I am asked about it I must reflect your viewpoint on it? I should expect that when my opinion is asked, my opinion is what should be given. And my opinion doesn't have to be politically correct, or stated in a politically correct way, any more than yours does.

Now, let's think about your statement that I said that something other than IP6 was on the standards track as IPng. According to the report, I said:

> ''They [NATs, CIDR, etc] are Band-Aids, but they're very effective
> Band-Aids,'' Baker said. ''If we run out of addresses in 2008,
> we're going to need something at that point. Is that going to be IPv6 or
> our we going to have a better idea by then?''

That's not quite what I said - that last was, if my memory serves, not a question, but a statement - at that point, we would likely deploy IP6, but if we had a better idea between now and then, we would deploy the better technology. But let's assume for the sake of argument that this sorry excuse for journalism was perfectly accurate. Explain to me how you get your statement out of what mine is reported to have been?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 NT 5: the power of Windows, the simplicity of Unix.

> You guys were a little rough on geographic addressing last week.
How insensistive of us! :-)

> It can work, just not in an architecture that resembles the current > Internet architecture.
That much I might agree with - although I doubt you'd like the net it was true of! Here's the "counterargument", in a few steps.

1 - There has to be a "loose congruence" between the addresses (in the sense of "routing-names") and the physical connectivity in vary large network, for the routing overhead to scale reasonably.

2 - Once can achieve this in two ways: i) one can constrain the addresses to follow the actual connectivity (i.e. connectivity-based addresses), or ii) one can adopt an addressing structure (e.g. geographic addressing) and constrain the topology to follow that.

3a - The physical connectivity will grow up in response to actual user traffic patterns.

3b - The Internet has no mechanism for enforcing topology control, and it's probably "politically" infeasible to create such a network.

4 Logic says that proposition 2-ii is inconsistent with both observation 3a and 3b, leaving 2-i as the only possible path of action.

If you can point out the flaw in this line of reasoning, I would be very interested to hear it.

> I believe that location independent names are an application layer
> problem not a network layer problem. One shouldn't try to solve all
> problem in all layers.
The latter is certainly true, but then again is it really useful for each application to build the approximate same support for portability and mobility, over and over again? Surely that part which is common ought to be lower down, no?

Noel

A summary of the IAB's proposals in response to the work of the ROAD group.

----------------------------------------------------------------------

The IAB's analysis of the many possibilities suggested by these two reports led it to the following conclusions, which are docu- mented in an internet-draft entitled "IP Version 7":

1. The ROAD group's work, compiled over a period of four months, makes it very clear that the problems of too few IP addresses and too many Internet routes are real and immediate, and represent a clear and present danger to the future successful growth of the worldwide Internet. The IAB was therefore unable to agree with the IESG recommendation to pursue an additional six-month program of further analysis before deciding on a plan for dealing with the ROAD problems. The detailed design, engineering, and deployment work must begin now, and it is therefore imperative that the efforts of the Internet community be focussed on a common goal.

2. The IETF should aggresively pursue the work to engineer CIDR ("classless inter-domain routing", described in RFC 1338), including the extensions to the inter-AD routing protocols to support variable-length masks/prefixes, and the associated address administration paradigm.

3. Since CIDR postpones, but does not prevent, the eventual exhaustion of the 32-bit IP address space, the IETF should also aggressively pursue a detailed technical and organizational plan for using CLNP (the OSI internetwork protocol defined by the ISO 8473 standard, which uses 160-bit addresses) as the basis for a new version of IP (which we have dubbed "IP version 7"), succeeding over time the current version of IP (version 4) in the Internet. An initial description of how CLNP could be used for this purpose within the current TCP/IP architecture and with the existing Internet applications is described in RFC 1347.

4. CLNP has larger addresses than IP, but like IP it lacks features that are expected to be necessary to support future Internet appli- cations and services. The IAB therefore also encourages the pursuit of research in areas such as policy-based routing, route preallocation and cacheing, and deterministic end-to-end QOS mainten- ance (for real-time and other delay-variance sensitive traffic).

There are, of course, many issues that must be resolved before CIDR and IPv7 can actually be deployed in the operational Internet. No one should imagine that there is not still a great deal of work to be done, notwith- standing the efforts that have already been expended by several of the IETF working groups and by the members of the ROAD group over the past year.

In recommending that the ROAD problems be addressed by a combination of CIDR, IPv7, and further research, the IAB has deliberately chosen NOT to recommend any of the possible alternatives, so as to present a single focal point for the community consisting of what we believe to be the best technical solutions to the problems. This should not be construed as a blanket "condemnation" of the alternative proposals that have been floated in various parts of the IETF. However, we believe that the normal IETF process of "let a thousand [proposals] bloom", in which the "right choice" emerges gradually and naturally from a dialectic of deployment and experimentation, would in this case expose the community to too great a risk that the Internet will drown in its own explosive success before the process had run its course. The IAB does not take this step lightly, nor without regard for the Internet traditions that are unavoidably offended by it. We look forward to a lively discussion of these conclusions during the upcoming IETF meeting in Boston.

- Lyman Chapin
IAB chair

Re: Milo going Nova.
Hans-Werner Braun (hwb@upeksa.sdsc.edu)
Fri, 3 Jul 92 22:13:58 PDT
Previous message: Bob Hinden: "Comments on IPv7 Document"

Lixia:
>some special effort out of this
>community in the next few months may well present a solution in time.

That would certainly be ok with me, but would require more than some protocol specification. Scalability is not only a technical term these days. It is quite worrysome to see how many dependencies there are on the network, and what it would take to make solutions viable, acceptable, implementable and manageable, including in a global and also quite politicized arena. It seems to me at times that a technical specification is not the biggest problem to solve any more, unlike in the DARPA days, where advanced ideas were much more welcome and applicable for the network at hand.

Today in many cases it seems to take a year or so to to just find funding for new effort, to even just *start* the development of a specification. The environment is much more complicated today than in the 1984 DARPA days you point to, there are many sharks out there, and lots of people critically depend on services that must not be interrupted. The time has come that we have to realize that the importance of the network is reaching towards the importance of telephony networks, with national securities and billions of dollars at stake. Not to lessen their importance, but research and development has to be decoupled from the operational infrastructure in order to retain a large scale manageable situation. It is not easy to make judgments. There is no completely right solution, as there will be compromises somewhere, in whatever solutions people will propose; even if someone would come up with a protocol for generations to come.

Hans-Werner

>Correct. Why? They don't represent anyone. As I said ITU is a
>different matter.
>
>Take care,
>John

Remember this? :-)

           The ISO Reference Model

             +---------------+
             |   Politics    | <----- You are here.
             +---------------+
             |  Application  |
             +---------------+
             | Presentation  |
             +---------------+
             |   Session     |
             +---------------+
             |   Transport   |
             +---------------+
             |    Network    |
             +---------------+
             |   Data Link   |
             +---------------+
             |   Physical    |
             +---------------+

- paul

Date sent: Wed, 12 Nov 1997 03:45:08 -0800
To: bound@zk3.dec.com
From: Fred Baker <fred@cisco.com>
Subject: (IPng 4787) Re: Hello Fred - IPv6 is IPng
Copies to: ipng@sunroof.Eng.Sun.COM

At 7:39 PM -0500 11/10/97, bound@zk3.dec.com wrote:

>Sitting here in this WG I am unclear that you as IETF Chair understand
>all the IPng issues per RFC 1752. None of what you mention as IETF
>Chair (Jim Duffy is quoting you in your role not as individual) fixes
>the problems with IPv4 for many of the issues in 1752 IMO. But I am
>more concerned about your statement of "something better" IPv6 is
>being tracked for a Global Internet Standard.

There are several things that concern me here, some of which are in your note and some of which are in his article.

I would describe his article as a particularly poor bit of reporting. I spoke for some 45 minutes on the subject of the trends that I personally (not the IETF corporately) see as important in the Internet for the next few years, which have to do with putting an economic underpinning under the net in the form of what the Integrated Services folks call the Differentiated Services model. This basically calls for and enables the Internet to provide best effort services with a business model more like a telco's. Note that the primary subject of the talk, what I discussed for at least 30 out of those 45 minutes, is not mentioned in his report. That is, at best, incomplete reporting.

When the talk was over, I was asked a few questions, one of which was "you didn't mention IP6 - why not?" The answer was simple enough - I didn't mention IP4 either. IP4 has facilities that can be used to deploy the Differentiated Services model, and as IP4 is in place today and will be predominant for the foreseeable future (which I stated during that Q&A to be "until we all walk into the hall to get coffee", but which I think will probably be until after both of us retire), is the first vehicle that will be used to deploy this. IP6, last we discussed this subject on this mailing list, was in danger of having its priority field removed and has no TOS flags, and therefore doesn't presently have the facilities necessary to deploy Van Jacobsen's "Pre-emptive Service" and was at least at one point in time considering being unable to deploy Clark's "Assured Service". So IP6 may or may not be able to support the facilities that I see as critical to the Internet over the coming years. That remains to be seen.

I did not say that something else was on the standards track for IPng. What I said - and he got parts of the quote right - was that the initial urgency of deploying an IPng has been mitigated by developments such as CIDR, NATs, DHCP, and private address spaces. No comment on the architectural aspects of that - frankly, there are serious architectural problems with NATs, not the least of which is a single point of failure, the loss of which forces an end to end restart of TCP sessions. But what we thought at one time we might be forced to deploy as early as 1993 looks like (according to Frank Solenski's Address Usage statistics the last time I saw them) it might not be needed for as much as another decade. And in that time - well, maybe your crystal ball is clearer than mine, but my crystal ball doesn't preclude somebody having a better idea than IP6 as presently formulated. If we do indeed have a better idea in the meantime, I said, we would deploy said better idea.

If you want my concerns with IP6, I think you are already in receipt of them. But I'll give you a little list.

First, as I say, I think scalable differentiated services of some form are mission critical, and I think that this does not imply RSVP or any other per-flow state negotiation over the backbone. Per-flow state negotiation using protocols such as RSVP is important in unregulated portions of the net such as corporate networks, but when the data enters a service provider's transit network, such things will be managed by contract, and therefore by message attributes, rather than by maintenance of per-flow state. Question of applicability space.

Second, I think the flow label in IP6 is poorly designed. One needs something akin to what it is now fashionable to call "label switching" to do special-flow QoS in a scalable fashion. We can do it at the IP layer or at a layer one below, it really doesn't matter to me.

Third, the address size discriminates against low delay applications on low speed lines. Say it any way you want to, I don't care, but take this example and think about it. On an ISDN basic rate line (128 KBPS in two B channels), I can place two standard telephone calls using voice technology, and perhaps three VoIP calls if I use IP4, or two voice calls plus miscellaneous best effort traffic such as web and email exchanges. VoIP uses a compression technique that sends standard voice at about 40 messages a second comprising an 8-16 KHz voice bit stream. The difference between an IP4 and an IP6 header is an additional 20 bytes (if memory serves), which means that using IP6, I will get two voice calls on that same line, no more. The stated ROAD requirement was for an address that would identify 10^12 networks and 10^15 hosts, which is achievable with a 64 bit address at a usage density of only one address in 16,000 - where the moaning I hear today is that folks (deplorably) use about one address in one hundred. I'm sorry, nobody has ever given me an explanation for the bloated 128 bit fixed size address that I could correlate to the requirements the address had to meet, and I see the address as hurting interactive, transaction, and real time applications on the most widely deployed links in the world - T-1 and below.

From my perspective, if a typical network administrator can do all of his work using either IP4 or IP6, and he gets better service (higher throughput and lower delay on the delay-sensitive applications that his users form their impressions of his network from) on IP4 using economical lines, while IP6 pushes him toward higher cost lines, I should expect the typical network administrator is going to delay introduction of IP6 as long as possible. I don't see how he could otherwise defend his job. And until there is someone else using IP6 that he *has* to use IP6 to talk to, and he *has* to talk with him, I don't see any community of interest that he serves requesting IP6 services by name. The laws of the marketplace militate for "IP4 with band-aids" over IP6 with a vengeance. Note that I am not speaking, in that, as a detractor of IP6. I am speaking as a practical person with a finite wallet about how people like me behave in the marketplace, whether that marketplace is the grocery store, the hardware store, the corporate budget cycle, or the Internet.

So much for the issues in the article. Now for my issues with your note.

Jim, you live in a state whose motto is "live free or die". You live with that fundamental ethic in your daily life, and you display that ethic in the messages you send to the net and your interactions in IETF meetings. Do you have a problem with other people also living by that ethic? When I am asked to speak about the issues that I see (from my vantage point as IETF chair) as critical trends over the next few years, where does it say that I must reflect your marketing viewpoint? Where does it say that I must mention your favorite work item, or that if I am asked about it I must reflect your viewpoint on it? I should expect that when my opinion is asked, my opinion is what should be given. And my opinion doesn't have to be politically correct, or stated in a politically correct way, any more than yours does.

Now, let's think about your statement that I said that something other than IP6 was on the standards track as IPng. According to the report, I said:

>''They [NATs, CIDR, etc] are Band-Aids, but they're very effective
>Band-Aids,'' Baker said. ''If we run out of addresses in 2008,
>we're going to need something at that point. Is that going to be IPv6 or
>our we going to have a better idea by then?''

That's not quite what I said - that last was, if my memory serves, not a question, but a statement - at that point, we would likely deploy IP6, but if we had a better idea between now and then, we would deploy the better technology. But let's assume for the sake of argument that this sorry excuse for journalism was perfectly accurate. Explain to me how you get your statement out of what mine is reported to have been?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

From: bound@zk3.dec.com
To: fred@cisco.com
Copies to: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 4775) Hello Fred - IPv6 is IPng
Date sent: Mon, 10 Nov 1997 19:39:50 -0500

Fred,
Sitting here in this WG I am unclear that you as IETF Chair understand all the IPng issues per RFC 1752. None of what you mention as IETF Chair (Jim Duffy is quoting you in your role not as individual) fixes the problems with IPv4 for many of the issues in 1752 IMO. But I am more concerned about your statement of "something better" IPv6 is being tracked for a Global Internet Standard.

/jim

http://www.nwfusion.com/news/1105ipv6.html
                  ----------------------------------------------
                  IETF head questions need for IPv6
                  By Jim Duffy
                  Network World Fusion, 11/5/97

                  Arlington, Va. - The chairman of the
                  IETF today questioned whether the
                  industry needs to migrate to IPv6, a
                  revision of the venerable Internet
                  Protocol designed to preserve
                  addresses.

                  After delivering a keynote address on
                  the future of the Internet at the
                  Next Generation Networks conference
                  here, IETF Chairman Fred Baker was
                  asked why his remarks did not include
                  even a mention of IPv6.

                  ''I'm not sure where IPv6 is going,''
                  Baker replied. ''It turns out we had
                  other things we could do (to preserve
                  IP addresses),'' such as network
                  address translators, Classless
                  Interdomain Routing (CIDR) and
                 Dynamic Host Configuration
                  Protocol,(DHCP)he said.

                  ''They're Band-Aids, but they're very effective
                  Band-Aids,'' Baker said. ''If we run out of
                  addresses in 2008, we're going to need something at
                  that point. Is that going to be IPv6 or our we going
                  to have a better idea by then?''

                  Nonetheless, the IETF will continue to work on IPv6,
                  said Baker, who is also a senior software engineer
                  at Cisco Systems, Inc. The IETF also is working on
                  enhancements to the Transmission Control Protocol,
                  such as selective acknowledgement and large window
                  sizes, Baker said. He said Microsoft Corp. will
                  include these enhancements in its Windows 98
                  operating system which is slated to ship in the
                  first half of next year.

                   ---------------------------------------------------
                   -----
                        Feedback | Network World, Inc. | Sponsor index
                                 How to Advertise | Copyright

                        Home | NetFlash | This Week | Industry/Stocks
                   Buyer's Guides/Tests | Net Resources | Opinions |
                   Careers

                            Seminars & Events | Product Demos/Info
                                   Audio Primers | IntraNet


------- End of Forwarded Message

Fred, Jim,

I would strongly encourage the two of you to take the personal discussion off the IPng list. It is not appropriate for the working group mailing list.

Fred,

Steve Deering and I will respond later to the technical concerns you raise about IPv6. I think your technical concerns are largely misplaced and suspect that you have not been following the work in enough detail to know that there are easy answers to the questions you raise.

Bob