diff options
Diffstat (limited to 'doc/rfc/rfc1687.txt')
| -rw-r--r-- | doc/rfc/rfc1687.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc1687.txt b/doc/rfc/rfc1687.txt new file mode 100644 index 0000000..577fbbf --- /dev/null +++ b/doc/rfc/rfc1687.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group E. Fleischman +Request for Comments: 1687 Boeing Computer Services +Category: Informational August 1994 + + + A Large Corporate User's View of IPng + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document was submitted to the IETF IPng area in response to RFC + 1550. Publication of this document does not imply acceptance by the + IPng area of any ideas expressed within. Comments should be + submitted to the big-internet@munnari.oz.au mailing list. + +Disclaimer and Acknowledgments + + Much of this draft has been adapted from the article "A User's View + of IPng" by Eric Fleischman which was published in the September 1993 + edition of ConneXions Magazine (Volume 7, Number 9, pages 36 - 40). + The original ConneXions article represented an official position of + The Boeing Company on IPng issues. This memo is an expansion of that + original treatment. This version also represents a Boeing corporate + opinion which we hope will be helpful to the on-going IPng + discussions. An assumption of this paper is that other Fortune 100 + companies which have non-computing-related products and services will + tend to have a viewpoint about IPng which is similar to the one + presented by this paper. + +Executive Summary + + Key points: + + 1) Large corporate users generally view IPng with disfavor. + + 2) Industry and the IETF community have very different values + and viewpoints which lead to orthogonal assessments concerning + the desirability of deploying IPng. + + 3) This paper provides insight into the mindset of a large + corporate user concerning the relevant issues surrounding an + IPng deployment. The bottom line is that a new deployment of + IPng runs counter to several business drivers. A key point to + + + +Fleischman [Page 1] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + + highlight is that end users actually buy applications -- not + networking technologies. + + 4) There are really only two compelling reasons for a large end + user to deploy IPng: + + A) The existence of must-have products which are tightly coupled + with IPng. + B) Receipt of a command to deploy IPng from senior management. + The former would probably be a function of significant + technological advances. The latter probably would be a + function of a convergence of IPng with International + Standards (OSI). + + 5) Five end user requirements for IPng are presented: + + A) The IPng approach must permit piecemeal transitions. + B) The IPng approach must not hinder technological advances. + C) The IPng approach is expected to foster synergy with + International Standards (OSI). + D) The IPng approach should have "Plug and Play" networking + capabilities. + E) The IPng approach must have network security characteristics + which are better than existing IPv4 protocols. + +Introduction + + The goal of this paper is to examine the implications of IPng from + the point of view of Fortune 100 corporations which have heavily + invested in TCP/IP technology in order to achieve their (non-computer + related) business goals. + + It is our perspective that End Users currently view IPng with + disfavor. This note seeks to explain some of the reasons why an end + user's viewpoint may differ significantly from a "traditional IETF" + perspective. It addresses some of the reasons which cause IPng to be + viewed by end users as a "threat" rather than as an "opportunity". + It enumerates some existing End User dissatisfactions with IPv4 + (i.e., current TCP/IP network layer). These dissatisfactions may + perhaps be eventually exploited to "sell" IPng to users. Finally, it + identifies the most compelling reasons for end users to deploy IPng. + In any case, the IETF community should be warned that their own + enthusiasm for IPng is generally not shared by end users and that + convincing end users to deploy IPng technologies may be very + difficult -- assuming it can be done at all. + + + + + + +Fleischman [Page 2] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + +The Internet and TCP/IP Protocols are not Identical + + The Internet Engineering Task Force (IETF) community closely + associates TCP/IP protocols with the Internet. In many cases it is + difficult to discern from the IETF perspective where the world-wide + Internet infrastructure ends and the services of the TCP/IP Protocol + Suite begin -- they are not always distinguishable from each other. + Historically they both stem from the same roots: DARPA was the + creator of TCP/IP and of the seminal "Internet". The services + provided by the Internet have been generally realized by the "TCP/IP + protocol family". The Internet has, in turn, become a primary + vehicle for the definition, development, and transmission of the + various TCP/IP protocols in their various stages of maturity. Thus, + the IETF community has a mindset which assumes that there is a strong + symbiotic relationship between the two. + + End users do not share this assumption -- despite the fact that many + end users have widely deployed TCP/IP protocols and extensively use + the Internet. It is important for the IETF community to realize, + however, that TCP/IP protocols and the Internet are generally viewed + to be two quite dissimilar things by the large end user. That is, + while the Internet may be a partial selling point for some TCP/IP + purchases, it is rarely even a primary motivation for the majority of + purchases. Many end users, in fact, have sizable TCP/IP deployments + with no Internet connectivity at all. Thus, many end users view the + relationship between the Internet and TCP/IP protocols to be tenuous + at best. + + More importantly, many corporations have made substantial investments + in (non-Internet) external communications infrastructures. A variety + of reasons account for this including the fact that until recently + the Internet was excluded from the bilateral agreements and + international tariffs necessary for international commerce. In any + case, end users today are not (in the general case) dependent upon + the Internet to support their business processes. [Note: the + previous sentence does not deny that many Fortune 100 employees (such + as the author) are directly dependent upon the Internet to fulfill + their job responsibilities: The Internet has become an invaluable + tool for many corporations' "research and education" activities. + However, it is rarely used today for activities which directly affect + the corporations' financial "bottom line": commerce.] By contrast, + large End Users with extensive internal TCP/IP deployments may + perhaps view TCP/IP technology to be critically important to their + corporation's core business processes. + + + + + + + +Fleischman [Page 3] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + +Security Islands + + Another core philosophical difference between large end users and the + IETF is concerning the importance of Security Islands (i.e., + firewalls). The prevalent IETF perspective is that Security Islands + are "A Bad Thing". The basic IETF assumption is that the + applications they are designing are universally needed and that + Security Islands provide undesirable filters for that usage. That + is, the IETF generally has a world view which presupposes that data + access should be unrestricted and widely available. + + By contrast, corporations generally regard data as being a + "sensitive" corporate asset: If compromised the very viability of + the corporation itself may in some cases be at risk. Corporations + therefore presuppose that data exchange should be restricted. + + Large end users also tend to believe that their employees have + differing data access needs: Factory workers have different + computing needs than accountants who have different needs than + aeronautical engineers who have different needs than research + scientists. A corporation's networking department(s) seeks to ensure + that each class of employee actually receives the type of services + they require. A security island is one of the mechanisms by which + the appropriate service levels may be provided to the appropriate + class of employee, particularly in regards to external access + capabilities. + + More importantly, there are differing classes of computer resources + within a corporation. A certain percentage of these resources are + absolutely critical to the continuing viability of that corporation. + These systems should never (ever) be accessible from outside of the + company. These "corporate jewels" must be protected by viable + security mechanisms. Security islands are one very important + component within a much larger total security solution. + + For these reasons we concur with the observation made by Yakov + Rekhter (of IBM) and Bob Moskowitz (of Chrysler) in their joint + electronic mail message of January 28, 1994. They wrote: + + "Hosts within sites that use IP can be partitioned into three + categories: + + - hosts that do not require Internet access. + - hosts that need access to a limited set of Internet + services (e.g., Email, FTP, netnews, remote login) which can + be handled by application layer relays. + - hosts that need unlimited access (provided via IP + connectivity) to the Internet." + + + +Fleischman [Page 4] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + + The exact mechanism by which a corporation will satisfy the differing + needs of these three classes of devices must be independently + determined by that corporation based upon a number of internal + factors. Each independent solution will determine how that + corporation defines their own version of "security island". + + Thus, if end users use the Internet at all, they will generally do so + through a "security island" of their own devising. The existence of + the security island is yet another element to (physically and + emotionally) decouple the End User from the Internet. That is, while + the end user may use the Internet, their networks (in the general + case) are neither directly attached to it nor are their core business + processes today critically dependent upon it. + +Networking from a Large End User's Perspective + + The following five key characteristics describe Boeing's environment + and are probably generally representative of other large TCP/IP + deployments. The author believes that an understanding of these + characteristics is very important for obtaining insight into how the + large end user is likely to view IPng. + + 1) Host Ratio + + Many corporations explicitly try to limit the number of their + TCP/IP hosts that are directly accessible from the Internet. This + is done for a variety of reasons (e.g., security). While the + ratio of those hosts that have direct Internet access capabilities + to those hosts without such capabilities will vary from company to + company, ratios ranging from 1:1000 to 1:10,000 (or more) are not + uncommon. The implication of this point is that the state of the + world-wide (IPv4) Internet address space only directly impacts a + tiny percentage of the currently deployed TCP/IP hosts within a + large corporation. This is true even if the entire population is + currently using Internet-assigned addresses. + + 2) Router-to-Host Ratio + + Most corporations have significantly more TCP/IP hosts than they + have IP routers. Ratios ranging between 100:1 to 600:1 (or more) + are common. The implication of this point is that a transition + approach which solely demands changes to routers is generally much + less disruptive to a corporation than an approach which demands + changes to both routers and hosts. + + + + + + + +Fleischman [Page 5] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + + 3) Business Factor + + Large corporations exist to fulfill some business purpose such as + the construction of airplanes, baseball bats, cars, or some other + product or service offering. Computing is an essential tool to + help automate business processes in order to more efficiently + accomplish the business goals of the corporation. Automation is + accomplished via applications. Data communications, operating + systems, and computer hardware are the tools used by applications + to accomplish their goals. Thus, users actually buy applications + and not networking technologies. The central lesson of this point + is that IPng will be deployed according to the applications which + use it and not because it is a better technology. + + 4) Integration Factor + + Large corporations currently support many diverse computing + environments. This diversity limits the effectiveness of a + corporation's computing assets by hindering data sharing, + application interoperability, "application portability", and + software re-usability. The net effect is stunted application life + cycles and increased support costs. Data communications is but + one of the domains which contribute towards this diversity. For + example, The Boeing Company currently has deployed at least + sixteen different protocol families within its networks (e.g., + TCP/IP, SNA, DECnet, OSI, IPX/SPX, AppleTalk, XNS, etc.). Each + distinct Protocol Family population potentially implies unique + training, administrative, support, and infrastructure + requirements. Consequently, corporate goals often exist to + eliminate or merge diverse Data Communications Protocol Family + deployments in order to reduce network support costs and to + increase the number of devices which can communicate together + (i.e., foster interoperability). This results in a basic + abhorrence to the possibility of introducing "Yet Another + Protocol" (YAP). Consequently, an IPng solution which introduces + an entirely new set of protocols will be negatively viewed simply + because its by-products are more roadblocks to interoperability + coupled with more work, expense, and risk to support the end + users' computing resources and business goals. Having said this, + it should be observed that this abhorrence may be partially + overcome by "extenuating circumstances" such as applications using + IPng which meet critical end-user requirements or by broad + (international) commercial support. + + + + + + + + +Fleischman [Page 6] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + + 5) Inertia Factor + + There is a natural tendency to continue to use the current IP + protocol (IPv4) regardless of the state of the Internet's IPv4 + address space. Motivations supporting inertia include the + following: existing application dependencies (including + Application Programming Interface (API) dependencies); opposition + to additional protocol complexity; budgetary constraints limiting + additional hardware/software expenses; additional address + management and naming service costs; transition costs; support + costs; training costs; etc. As the number of Boeing's deployed + TCP/IP hosts continues to grow towards the 100,000 mark, the + inertial power of this population becomes increasingly strong. + However, inertia even exists with smaller populations simply + because the cost to convert or upgrade the systems are not + warranted. Consequently, pockets of older "legacy system" + technologies often exist in specific environments (e.g., we still + have pockets of the archaic BSC protocol). The significance of + this point is that unless there are significant business benefits + to justify an IPng deployment, economics will oppose such a + deployment. Thus, even if the forthcoming IPng protocol proves to + be "the ultimate and perfect protocol", it is unrealistic to + imagine that the entire IPv4 population will ever transition to + IPng. This means that should we deploy IPng within our network, + there will be an ongoing requirement for our internal IPng + deployment to be able to communicate with our internal IPv4 + community. This requirement is unlikely to go away with time. + +Address Depletion Doesn't Resonate With Users + + Thus, the central, bottom-line question concerning IPng from the + large corporate user perspective is: What are the benefits which + will justify the expense of deploying IPng? + + At this time we can conceive of only four possible causes which may + motivate us to consider deploying IPng: + + Possible Cause: Possible Corporate Response: + + 1) Many Remote (external) Peers Gateway external systems only. + solely use IPng. + + 2) Internet requires IPng usage. Gateway external systems only. + + 3) "Must have" products are tightly Upgrade internal corporate + coupled with IPng (e.g., "flows" network to support IPng where + for real-time applications). that functionality is needed. + + + + +Fleischman [Page 7] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + + 4) Senior management directs IPng Respond appropriately. + usage. + + It should explicitly be noted that the reasons which are compelling + the Internet Community to create IPng (i.e., the scalability of IPv4 + over the Internet) are not themselves adequate motivations for users + to deploy IPng within their own private networks. That is, should + IPng usage become mandated as a prerequisite for Internet usage, a + probable response to this mandate would be to convert our few hosts + with external access capabilities to become IPng-to-IPv4 + application-layer gateways. This would leave the remainder of our + vast internal TCP/IP deployment unchanged. Consequently, given + gateways for external access, there may be little motivation for a + company's internal network to support IPng. + +User's IPv4 "Itches" Needing Scratching + + The end user's "loyalty" to IPv4 should not be interpreted to mean + that everything is necessarily "perfect" with existing TCP/IP + deployments and that there are therefore no "itches" which an + improved IPv4 network layer -- or an IPng -- can't "scratch". The + purpose of this section is to address some of the issues which are + very troubling to many end users: + + A) Security. TCP/IP protocols are commonly deployed upon broadcast + media (e.g., Ethernet Version 2). However, TCP/IP mechanisms to + encrypt passwords or data which traverse this media are + inadequate. This is a very serious matter which needs to be + expeditiously resolved. An integrated and effective TCP/IP + security architecture needs to be defined and become widely + implemented across all venders' TCP/IP products. + + B) User Address Space privacy. Current IPv4 network addressing + policies require that end users go to external entities to obtain + IP network numbers for use in their own internal networks. These + external entities have the hubris to determine whether these + network requests are "valid" or not. It is our belief that a + corporation's internal addressing policies are their own private + affair -- except in the specific instances in which they may + affect others. Consequently, a real need exists for two classes + of IPv4 network numbers: those which are (theoretically) visible + to the Internet today (and thus are subject to external + requirements) and those which will never be connected to the + Internet (and thus are strictly private). We believe that the + concept of "local addresses" is a viable compromise between the + justifiable need of the Internet to steward scarce global + resources and the corporate need for privacy. "Local addresses" + by definition are non-globally-unique addresses which should + + + +Fleischman [Page 8] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + + never be routed (or seen) by the Internet infrastructure. + + We believe that 16 contiguous Class B "local addresses" need to + immediately be made available for internal corporate usage. Such + an availability may also reduce the long-term demand for new IPv4 + network numbers (see RFC 1597). + + C) Self-Defining Networks. Large End Users have a pressing need for + plug-and-play TCP/IP networks which auto-configure, auto-address, + and auto-register. End users have repeatedly demonstrated our + inability to make the current manual methods work (i.e., heavy + penalties for human error). We believe that the existing DHCP + technology is a good beginning in this direction. + + D) APIs and network integration. End users have deployed many + differing complex protocol families. We need tools by which + these diverse deployments may become integrated together along + with viable transition tools to migrate proprietary + alternatives to TCP/IP-based solutions. We also desire products + to use "open" multi-vendor, multi-platform, exposed Application + Programming Interfaces (APIs) which are supported across several + data communications protocol "families" to aid in this + integration effort. + + E) International Commerce. End users are generally unsure as to + what extent TCP/IP can be universally used for international + commerce today and whether this is a cost-effective and "safe" + option to satisfy our business requirements. + + F) Technological Advances. We have ongoing application needs which + demand a continual "pushing" of the existing technology. Among + these needs are viable (e.g., integratable into our current + infrastructures) solutions to the following: mobile hosts, + multimedia applications, real-time applications, very + high-bandwidth applications, improved very low-bandwidth (e.g., + radio based) applications, standard-TCP/IP-based transaction + processing applications (e.g., multi-vendor distributed + databases). + + Only Two Motivations For Users To Deploy IPng + + Despite this list of IPv4 problem areas, we suspect that there are + only two causes which may motivate users to widely deploy IPng: + + (1) If IPng products add critical functionality which IPv4 can't + provide (e.g., real time applications, multimedia applications, + genuine (scalable) plug-and-play networking, etc.), users would be + motivated to deploy IPng where that functionality is needed. + + + +Fleischman [Page 9] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + + However, these deployments must combat the "Integration Factor" + and the "Inertia Factor" forces which have previously been + described. This implies that there must be a significant business + gain to justify such a deployment. While it is impossible to + predict exactly how this conflict would "play out", it is + reasonable to assume that IPng would probably be deployed + according to an "as needed only" policy. Optimally, specific + steps would be taken to protect the remainder of the network from + the impact of these localized changes. Of course, should IPng + become bundled with "killer applications" (i.e., applications + which are extremely important to significantly many key business + processes) then all bets are off: IPng will become widely + deployed. However, it also should be recognized that virtually + all (initial) IPng applications, unless they happen to be "killer + applications", will have to overcome significant hurdles to be + deployed simply because they represent risk and substantially + increased deployment and support costs for the end user. + + (2) Should IPng foster a convergence between Internet Standards + and International Standards (i.e., OSI), this convergence could + change IPng's destiny. That is, the networks of many large + corporations are currently being driven by sets of strong, but + contradictory, requirements: one set demanding compliance with + Internet Standards (i.e., TCP/IP) and another set demanding + compliance with International Standards. This paper assumes that + the reader is already familiar with the many reasons why end users + seek to deploy and use Internet Standards. The following is a + partial list as to why End Users may be motivated to use + International Standards (i.e., OSI) as well: + + A) World-wide commerce is regulated by governments in accordance + with their treaties and legal agreements. World-wide + telecommunications are regulated by the ITU (a United Nations + chartered/authorized organization). International Standards + (i.e., OSI) are the only government-sanctioned method for + commercial data communications. Aspects of this picture are + currently in the process of changing. + + B) The currently proprietary aeronautical world-wide air-to-ground + and ground-to-ground communications are being replaced by an + OSI-based (CLNP) Aeronautical Telecommunications Network (ATN) + internet which is being built in a number of different national + and international forums including: + + * International Civil Aviation Organization (ICAO) + * International Air Transport Association (IATA) + * Airlines Electronic Engineering Committee (AEEC) + + + + +Fleischman [Page 10] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + + "Civil Aviation Authorities, airlines, and private aircraft will + use the ATN to convey two major categories of data traffic among + their computers: Air Traffic Services Communications (ATSC) and + Aeronautical Industry Services Communication (AISC)." [Note: The + data communications of airline passengers are not addressed by + the directive.] + + C) A corporation's customers may have data communications + requirements which are levied upon them by the governments in + which they operate which they, in turn, must support in their + own products in order to fulfill their customers' needs. For + example, Boeing is influenced by existing: + + * Computer Aided Logistics Support (CALS; i.e., these are GOSIP + (OSI)-based) requirements for US Department of Defense + contractors. + * Airline requirements emanating from A and B above. + + D) The end user perception that once we have deployed + International Standards we will not subsequently be compelled to + migrate by external factors to another technology. Thus, we + would have a "safe" foundation to concentrate upon our real + computing issues such as increased customer satisfaction, + business process flow-time improvements, legacy system + modernization, and cost avoidance. + + E) The proposals of entities desiring to obtain contracts with + Governments are evaluated on many subjective and objective + bases. One of the subjective issues may well be the + "responsibility" and "dependability" of the bidder company + including such intangibles as its corporate like-mindedness. + For this reason, as long as the Government has OSI as their + official standard, the bidder may have a subjective advantage if + its corporate policy also includes a similar standard, + particularly if data communications services are being + negotiated. + + F) The perception that the need for IPng may imply that IPv4 is + unfit to be a strategic end user alternative. Also, IPng is not + a viable deployment option at this time. + + G) Doubts concerning IPv4 scalability (e.g., toasternet: an + algorithmic change in which currently "dumb devices" become + intelligent and suddenly require Internet connectivity). + + It currently appears that many of these "OSI motivations" are + undergoing change at this time. This possibility must be tracked + with interest. However, a key point of this section is that a + + + +Fleischman [Page 11] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + + corporation must base its data communications decisions upon business + requirements. That is, corporations exist to sell products and + services, not to play "networking games". + + Thus, if a means could be found to achieve greater synergy + (integration/ adoption) between Internet Standards and International + Standards then corporate management may be inclined to mandate + internal deployment of the merged standards and promote their + external use. Optimally, such a synergy should offer the promise of + reducing currently deployed protocol diversity (i.e., supports the + "Integration Factor" force). Depending on the specific method by + which this convergence is achieved, it may also partially offset the + previously mentioned "Inertia Factor" force, especially if IPng + proves to be a protocol which has already been deployed. + +User-based IPng Requirements + + From the above one can see that a mandate to use IPng to communicate + over the Internet does not correspondingly imply the need for large + corporate networks to generally support IPng within their networks. + Thus, while the IPv4 scalability limitations are a compelling reason + to identify a specific IPv4 replacement protocol for the Internet, + other factors are at work within private corporate networks. These + factors imply that large TCP/IP end users will have a continuing need + to purchase IPv4 products even after IPng products have become + generally available. + + However, since the IETF community is actively engaged in identifying + an IPng solution, it is desirable that the solution satisfy as many + end user needs as possible. For this reason, we would like to + suggest that the following are important "user requirements" for any + IPng solution: + + 1) The IPng approach must permit users to slowly transition to IPng + in a piecemeal fashion. Even if IPng becomes widely deployed, + it is unrealistic to expect that users will ever transition all + of the extensive IPv4 installed base to IPng. Consequently, the + approach must indefinitely support corporate-internal + communication between IPng hosts and IPv4 hosts regardless of + the requirements of the world-wide Internet. + + 2) The IPng approach must not hinder technological advances from + being implemented. + + 3) The IPng approach is expected to eventually foster greater + synergy (integration/adoption) between Internet Standards and + International Standards (i.e., OSI). [Note: This may be + accomplished in a variety of ways including having the Internet + + + +Fleischman [Page 12] + +RFC 1687 A Large Corporate User's View of IPng August 1994 + + + Standards adopted as International Standards or else having the + International Standards adopted as Internet Standards.] + + 4) The IPng approach should have "self-defining network" (i.e., + "plug & play") capabilities. That is, large installations + require device portability in which one may readily move devices + within one's corporate network and have them autoconfigure, + autoaddress, autoregister, etc. without explicit human + administrative overhead at the new location -- assuming that the + security criteria of the new location have been met. + + 5) The approach must have network security characteristics which are + better than existing IPv4 protocols. + +Conclusion + + In summary, the key factor which will determine whether -- and to + what extent -- IPng will be deployed by large end users is whether + IPng will become an essential element for the construction of + applications which are critically needed by our businesses. If IPng + is bundled with applications which satisfy critical business needs, + it will be deployed. If it isn't, it is of little relevance to the + large end user. Regardless of what happens to IPng, the large mass + of IPv4 devices will ensure that IPv4 will remain an important + protocol for the foreseeable future and that continued development of + IPv4 products is advisable. + +Security Considerations + + Security issues discussed throughout this memo. + +Author's Address + + Eric Fleischman + Network Architect + Boeing Computer Services + P.O. Box 24346, MS 7M-HA + Seattle, WA 98124-0346 USA + + EMail: ericf@atc.boeing.com + + + + + + + + + + + +Fleischman [Page 13] + |