rfc1687.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 732 行 · 第 1/3 页
TXT
732 行
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.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?