RFC 1687

A Large Corporate User's View of IPng 🦋

okay bestie, this is RFC 1687 and it's giving corporate-vs-IETF drama ✨

• Network Working Group 🌸
• Request for Comments: 1687 💖
• Title: A Large Corporate User's View of IPng
• Author: E. Fleischman, Boeing Computer Services 🎀
• Category: Informational 📚
• Date: August 1994 📅
• Obsoletes/Updates: the title block doesn't list anything this RFC obsoletes or updates 🙈

Status of this Memo 💅

so this is the legal-ish bit: this memo gives information to the Internet community. It does not specify an Internet standard of any kind, so it's not a rulebook. Distribution is unlimited, so share it with your friends 🫶

Abstract 🌈

this doc was submitted to the IETF IPng area in response to RFC 1550. Publishing it doesn't mean the IPng area accepted any of the ideas in it 🙈 Comments should be submitted to the big-internet@munnari.oz.au mailing list.

Disclaimer and Acknowledgments 🧚

this draft is 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, and this version also represents a Boeing corporate opinion that we hope will be helpful to the ongoing IPng discussions.

The author assumes that other Fortune 100 companies with non-computing-related products and services will tend to have a viewpoint about IPng that's similar to the one in this paper ✨

Executive Summary 🔥

key points, no filler:

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 about whether deploying IPng is desirable.
3. This paper gives insight into the mindset of a large corporate user about the relevant issues around an IPng deployment. The bottom line is that a new deployment of IPng runs counter to several business drivers. The big thing to highlight: 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 look at the implications of IPng from the point of view of Fortune 100 corporations that have heavily invested in TCP/IP technology to reach their (non-computer related) business goals 💼

okay real talk: end users currently view IPng with disfavor 😭 This note explains some reasons why an end user's viewpoint can be really different from a "traditional IETF" perspective. It covers why IPng can come across to end users as a "threat" instead of an "opportunity". It lists some existing End User dissatisfactions with IPv4 (i.e., the current TCP/IP network layer), which might eventually be used to "sell" IPng to users. And finally, it identifies the most compelling reasons for end users to deploy IPng.

The IETF community should be warned, though, that their own enthusiasm for IPng is generally not shared by end users. Convincing end users to deploy IPng technologies may be very difficult, assuming it can be done at all 🫠

The Internet and TCP/IP Protocols are not Identical 🌐

the IETF community closely associates TCP/IP protocols with the Internet 💖 In lots of cases it's hard to tell from the IETF perspective where the world-wide Internet infrastructure ends and the services of the TCP/IP Protocol Suite begin. They aren't always distinguishable from each other. Historically they come from the same roots: DARPA was the creator of TCP/IP and of the seminal "Internet". The services provided by the Internet have generally been 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. So the IETF community has a mindset that assumes there's a strong symbiotic relationship between the two.

end users do not share this assumption 👀 even though many of them have widely deployed TCP/IP protocols and extensively use the Internet. The IETF needs to realize that TCP/IP protocols and the Internet are generally viewed by the large end user as two quite dissimilar things. The Internet may be a partial selling point for some TCP/IP purchases, but it's rarely even a primary motivation for most of them. Many end users actually have sizable TCP/IP deployments with no Internet connectivity at all. So many end users see the relationship between the Internet and TCP/IP protocols as tenuous at best 🤷‍♀️

More importantly, lots of 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. Either way, end users today are not (in the general case) dependent on 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 view TCP/IP technology as critically important to their corporation's core business processes 🔥

Security Islands 🏝️

another core philosophical difference between large end users and the IETF is how important Security Islands (i.e., firewalls) are 🧱 The prevalent IETF perspective is that Security Islands are "A Bad Thing" 🙅‍♀️ The basic IETF assumption is that the applications they're designing are universally needed, and that Security Islands provide undesirable filters for that usage. Basically, the IETF generally has a world view that presupposes data access should be unrestricted and widely available.

corporations, on the other hand, generally regard data as a "sensitive" corporate asset 🔐 If it gets compromised, the very viability of the corporation itself may in some cases be at risk. So corporations presuppose that data exchange should be restricted.

Large end users also tend to believe 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 make sure each class of employee actually gets the type of services they require. A security island is one of the mechanisms by which the appropriate service levels can be provided to the appropriate class of employee, especially when it comes 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 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, the author concurs 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."

the exact mechanism a corporation uses to meet the differing needs of these three classes of devices must be figured out independently by that corporation, based on a bunch of internal factors 🧩 Each independent solution determines how that corporation defines its own version of "security island" 🌸

so if end users use the Internet at all, they'll generally do it through a "security island" of their own design 🏝️ The security island is yet another element that (physically and emotionally) decouples the End User from the Internet. Sure, the end user may use the Internet, but their networks (in the general case) are neither directly attached to it, nor are their core business processes today critically dependent on it 💅

Networking from a Large End User's Perspective ✨

okay bestie, this part is about how a huge company actually feels about networking 🏢💅 the author says these five key characteristics describe Boeing's environment, and they're probably pretty representative of other big TCP/IP setups 🫶 if you want to know how a large end user will react to IPng, you need to understand these. no cap 🔥

1) Host Ratio 🌸

okay so lots of companies try really hard to limit how many of their TCP/IP hosts can be reached directly from the Internet 🔒 they do this for a bunch of reasons, like security 🛡️ the ratio of hosts with direct Internet access to hosts without it changes from company to company, but ratios ranging from 1:1000 to 1:10,000 (or more) are not uncommon 🙈 so the state of the world-wide (IPv4) Internet address space only directly affects a tiny percentage of the TCP/IP hosts inside a big corp 💀 and that's true even when the whole population is using Internet-assigned addresses ✨

2) Router-to-Host Ratio 🎀

most corporations have way more TCP/IP hosts than IP routers 🖥️ ratios ranging between 100:1 to 600:1 (or more) are super common. so the translation is that a transition approach which only demands changes to routers is way less disruptive for a company than one which demands changes to both routers and hosts 🧚

3) Business Factor 💼

large corporations exist to fulfill some business purpose, like the construction of airplanes, baseball bats, cars, or some other product or service offering 🛩️⚾🚗 computing is an essential tool that helps automate business processes so the company can accomplish its goals more efficiently 🤖 automation is done through applications, and data communications, operating systems, and computer hardware are the tools those applications use to get their jobs done 🧰 so literally, users buy applications and not networking technologies 🛍️ the central lesson here 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 🌈 that diversity limits how effective a corporation's computing assets are, because it gets in the way of 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 only one of the domains contributing to 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 📚 so corporate goals often exist to eliminate or merge diverse Data Communications Protocol Family deployments, to reduce network support costs and increase the number of devices that can communicate together (i.e., foster interoperability) 🫶 this leads to a basic abhorrence of the possibility of introducing "Yet Another Protocol" (YAP) 🙅‍♀️ so 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 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 🌍✨

5) Inertia Factor 🐢

there's a natural tendency to keep using the current IP protocol (IPv4) regardless of the state of the Internet's IPv4 address space 🙃 the motivations behind this inertia include: 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 Boeing's deployed TCP/IP host count keeps growing toward the 100,000 mark, the inertial power of this population gets stronger and stronger 💪 inertia even exists with smaller populations, simply because the cost to convert or upgrade the systems isn't warranted 💸 so 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 📉 so even if the forthcoming IPng protocol proves to be "the ultimate and perfect protocol", it's unrealistic to imagine that the entire IPv4 population will ever transition to IPng 🫠 which 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 🤝 and this requirement is unlikely to go away with time ⏳

---

Address Depletion Doesn't Resonate With Users 📉

so the central, bottom-line question about IPng from the large corporate user's perspective is: what are the benefits which will justify the expense of deploying IPng? 💰

at this time we can only come up with four possible causes that 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.

   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 🔐 like, if IPng usage became mandated as a prerequisite for Internet usage, a probable response would be to convert our few hosts with external access capabilities into IPng-to-IPv4 application-layer gateways 🚪 that would leave the rest of our vast internal TCP/IP deployment unchanged 🏰 so, 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 🪩

Okay, so just because end users are super loyal to IPv4 does not mean everything is perfect with today's TCP/IP deployments 😭 There are still plenty of itches that an improved IPv4 network layer, or an IPng, could scratch ✨ This section is all about the stuff that's really bugging a lot of end users:

• A) Security. 🔐 TCP/IP protocols are commonly deployed on broadcast media (for example, Ethernet Version 2). But the TCP/IP mechanisms for encrypting passwords or data that travel over that media are inadequate. This is a very serious matter that needs to be resolved expeditiously 🚨 An integrated and effective TCP/IP security architecture needs to be defined and widely implemented across all vendors' TCP/IP products.
• B) User Address Space privacy. 🙈 Under current IPv4 addressing policies, end users have to go to external entities to get IP network numbers for their own internal networks. Those external entities get to decide whether these requests are "valid" or not, which is a LOT of power 💅 We believe that a corporation's internal addressing policies are its own private affair, except in the specific cases where they might affect others. So there is a real need for two classes of IPv4 network numbers: the ones that are (theoretically) visible to the Internet today, which are subject to external requirements, and the ones that will never be connected to the Internet, which are strictly private. We think the concept of "local addresses" is a viable compromise between the Internet's need to steward scarce global resources and the corporate need for privacy 🫶 "Local addresses" are, by definition, non-globally-unique addresses that should never be routed (or seen) by the Internet infrastructure.

We believe that 16 contiguous Class B "local addresses" need to be made available for internal corporate usage right away. That kind of 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 that auto-configure, auto-address, and auto-register. End users have repeatedly shown that the current manual methods just don't work for us, since human error comes with heavy penalties 💀 We believe that the existing DHCP technology is a good beginning in this direction.
• D) APIs and network integration. 🔗 End users have deployed many different complex protocol families. We need tools that let these diverse deployments get integrated together, along with viable transition tools to move proprietary alternatives over to TCP/IP-based solutions. We also want products that use "open" multi-vendor, multi-platform, exposed Application Programming Interfaces (APIs) supported across several data communications protocol "families" to help with that integration effort ✨
• E) International Commerce. 🌍 End users are generally unsure how far TCP/IP can be universally used for international commerce today, and whether it's a cost-effective and "safe" option for meeting our business requirements 🤔
• F) Technological Advances. 🚀 We have ongoing application needs that keep demanding that we keep "pushing" the existing technology. Among these needs are viable (for example, integratable into our current infrastructures) solutions for: mobile hosts, multimedia applications, real-time applications, very high-bandwidth applications, improved very low-bandwidth (for example, radio based) applications, and standard-TCP/IP-based transaction processing applications (for example, multi-vendor distributed databases) 💖

---

Only Two Motivations For Users To Deploy IPng 🎀

Despite this whole list of IPv4 problem areas, we suspect there are only two causes that might motivate users to widely deploy IPng 👑

(1) If IPng products add critical functionality that IPv4 can't provide (for example, real-time applications, multimedia applications, genuine (scalable) plug-and-play networking, and so on), users would be motivated to deploy IPng wherever that functionality is needed 🔥

But these deployments have to fight the "Integration Factor" and the "Inertia Factor" forces we described earlier 😩 That means there has to be a significant business gain to justify the deployment. It's impossible to predict exactly how this conflict will "play out", but it's reasonable to assume IPng would probably get deployed on an "as needed only" basis. Ideally, specific steps would be taken to protect the rest of the network from the impact of these localized changes. Of course, if IPng ever gets bundled with "killer applications" (that is, applications that are extremely important to significantly many key business processes), then all bets are off and IPng will become widely deployed 🏆 Still, it's also worth recognizing that virtually all (initial) IPng applications, unless they happen to be "killer applications", will have to overcome significant hurdles to get deployed, 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 (that is, OSI), this convergence could change IPng's destiny 🦋 Right now, the networks of many large corporations are being pulled in two directions by strong but contradictory requirements: one set demands compliance with Internet Standards (that is, TCP/IP), and another set demands compliance with International Standards. This paper assumes the reader already knows the many reasons end users want to deploy and use Internet Standards. Here's a partial list of why End Users might also be motivated to use International Standards (that is, OSI) 💅

• 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 (that is, OSI) are the only government-sanctioned method for commercial data communications. Parts of this picture are currently 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. It's 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)

"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 that are imposed on them by the governments where they operate. Those customers then need their own products to support these requirements in order to meet their customers' needs. For example, Boeing is influenced by existing:
  • Computer Aided Logistics Support (CALS; that is, 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 won't later be forced by external factors to migrate to another technology 🫶 That would give us a "safe" foundation to focus on our real computing issues, like increased customer satisfaction, business process flow-time improvements, legacy system modernization, and cost avoidance.
• E) Proposals from entities that want contracts with Governments are judged on many subjective and objective bases. One of the subjective issues may well be the "responsibility" and "dependability" of the bidder company, including intangibles like its corporate like-mindedness. For this reason, as long as the Government has OSI as its official standard, a 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 IPv4 is unfit to be a strategic end user alternative. Also, IPng is not a viable deployment option at this time 🙃
• G) Doubts about IPv4 scalability (for example, 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 changing right now, and this possibility has to be tracked closely 👀 But the key point of this section is that a corporation has to base its data communications decisions on business requirements. Corporations exist to sell products and services, not to play "networking games" 😤

So, if a way could be found to achieve greater synergy (integration/ adoption) between Internet Standards and International Standards, corporate management may be inclined to mandate internal deployment of the merged standards and promote their external use 🌈 Ideally, that kind of synergy would offer the promise of reducing currently deployed protocol diversity (that is, it supports the "Integration Factor" force) 🧩 Depending on how this convergence gets achieved, it may also partially offset the previously mentioned "Inertia Factor" force, especially if IPng proves to be a protocol that has already been deployed ⭐

User-based IPng Requirements 🎀

okay so, from everything above, a mandate to use IPng over the Internet does not automatically mean big corporate networks have to support IPng inside their own walls 🏢. The IPv4 scalability limits are a super valid reason to pick a specific IPv4 replacement for the Internet, but other stuff is going on in private corporate networks too ✨. So large TCP/IP end users are gonna keep needing to buy IPv4 products even after IPng products are generally available 💀.

however 🫶 the IETF crowd is actively working on picking an IPng solution, so it's desirable that the solution satisfies as many end user needs as possible 🌸. That's why we'd like to suggest the following as the important "user requirements" for any IPng solution, bestie 💅:

1. The IPng approach must permit users to slowly transition to IPng in a piecemeal fashion. Even if IPng becomes widely deployed, it's unrealistic to expect users will ever move the whole extensive IPv4 installed base over to IPng 😭. Consequently, the approach must indefinitely support corporate-internal communication between IPng hosts and IPv4 hosts, regardless of what the world-wide Internet needs 🌈.
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 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. Like, large installations need device portability, where you can readily move devices around your corporate network and have them autoconfigure, autoaddress, autoregister, etc. without explicit human administrative overhead at the new location -- assuming 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 ✨

so to sum it all up 🦋, the key factor deciding whether, and to what extent, large end users will deploy IPng is whether IPng becomes an essential element for building applications that our businesses critically need 💼. If IPng is bundled with applications that satisfy critical business needs, it'll get deployed. If it isn't, it's of little relevance to the large end user 🙈. Regardless of what happens to IPng, the large mass of IPv4 devices will keep IPv4 an important protocol for the foreseeable future, and continued development of IPv4 products is advisable 👑.

Security Considerations 🔐

Security issues discussed throughout this memo.

bestie, security is all throughout this memo, so don't skip past it 🙏

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