rfc1687.txt

<VC++网络游戏建摸与实现>源代码

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