RFC1687 日本語訳

1687 A Large Corporate User's View of IPng. E. Fleischman. August 1994. (Format: TXT=34120 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                      E. Fleischman
Request for Comments: 1687                      Boeing Computer Services
Category: Informational                                      August 1994

コメントを求めるワーキンググループE.フライシュマンの要求をネットワークでつないでください: 1687年のボーイングコンピュータサービスカテゴリ: 情報の1994年8月

                 A Large Corporate User's View of IPng

大きい企業ユーザーのIPngの視点

Status of this Memo

この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.

RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。

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.

この草稿の多くがエリック・フライシュマンによる「ユーザのIPngの視点」というConneXions Magazineの1993年9月の版で発表された記事から適合させられました(第7巻(Number9)は36--40を呼び出します)。 オリジナルのConneXions記事はIPng問題でボーイング社の公的立場を表しました。 このメモはそのオリジナルの処理の拡張です。 また、このバージョンは私たちが継続しているIPng議論に有用であることを望んでいるボーイングの法人の意見を表します。 この紙の仮定がそうしたその他のFortune100会社である、非、コンピューティング関連、製品とサービスは、この紙によって提示されたものと同様のIPngの周りに観点を持っている傾向があるでしょう。

Executive Summary

要約

   Key points:

要所:

   1)  Large corporate users generally view IPng with disfavor.

1) 一般に、大きい企業ユーザーは疎外でIPngを見ます。

   2)  Industry and the IETF community have very different values
       and viewpoints which lead to orthogonal assessments concerning
       the desirability of deploying IPng.

2) 産業とIETF共同体には、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

3) この紙は当該の問題周辺に関する大きい企業ユーザーの考え方に関する洞察にIPng展開を提供します。 結論はIPngの新しい展開が何人かのビジネスドライバーに反するということです。 要所

Fleischman                                                      [Page 1]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[1ページ]RFC1687

       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:

4) 本当に、大きいエンドユーザがIPngを配布する2つのやむにやまれない理由しかありません:

       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).

a) しっかりそうである絶対に必要なもの製品の存在はIPngに結合しました。 B) 経営幹部からIPngを配布するコマンドの領収書。 前者はたぶん重要な技術的進歩の機能でしょう。 後者はたぶん国際Standards(OSI)とのIPngの集合の機能でしょう。

   5)  Five end user requirements for IPng are presented:

5) IPngのための5つのエンドユーザ要件が提示されます:

       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.

a) IPngアプローチはばらばらの変遷を可能にしなければなりません。 B) IPngアプローチは技術的進歩を妨げてはいけません。 C) IPngアプローチが国際Standards(OSI)と共に相乗作用を伸ばすと予想されます。 D) IPngアプローチには、「Plug and Play」が、能力をネットワークでつなぎながら、あるべきです。 E) IPngアプローチには、既存のIPv4プロトコルより良いネットワークセキュリティの特性がなければなりません。

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.

この紙の目標はそれらの(非コンピュータは関係しました)企業目標を達成するために大いにTCP/IP技術に投資されたFortune100会社の観点からIPngの含意を調べることです。

   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.

エンドユーザが現在疎外でIPngを見るのは、私たちの見解です。 この注意はエンドユーザの観点が「伝統的なIETF」見解から有意差があるかもしれない理由のいくつかについて説明しようとします。 それはエンドユーザが「機会」としてというよりむしろ「脅威」としてIPngを見なす理由のいくつかを扱います。 それはIPv4(すなわち、現在のTCP/IPネットワーク層)と共にいくつかの既存のエンドユーザ不平を列挙します。 これらの不平は、結局、IPngをユーザに「販売すること」に恐らく利用されるかもしれません。 最終的に、それはエンドユーザがIPngを配布する最も無視できない理由を特定します。 どのような場合でも、それが全くできると仮定する場合、IETF共同体は一般に、IPngに対するそれら自身の熱意がエンドユーザによって共有されないで、IPngに技術を配布するようにエンドユーザを説得するのが非常に難しいかもしれないと警告されるべきです。

Fleischman                                                      [Page 2]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[2ページ]RFC1687

The Internet and TCP/IP Protocols are not Identical

インターネットとTCP/IPプロトコルは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.

インターネット・エンジニアリング・タスク・フォース(IETF)共同体は密接にTCP/IPプロトコルをインターネットに関連づけます。 TCP/IPプロトコルSuiteのサービスは始まります--多くの場合、IETF見解から世界的なインターネット基盤がどこで終わるかを明察するのが難しく、それらは互いからいつも区別可能であるというわけではありません。 歴史的に、それらの両方が同じルーツに由来します: DARPAはTCP/IPと精液の「インターネット」のクリエイターでした。 一般に、インターネットによって提供されたサービスは「TCP/IPプロトコルファミリー」によって実現されました。 インターネットは順番にそれらの様々なステージの円熟の様々なTCP/IPプロトコルの定義、開発、および送信のためのプライマリ手段になりました。 したがって、IETF共同体には、2つの間には、強い癒着があると仮定する考え方があります。

   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.

エンドユーザは、多くのエンドユーザが、TCP/IPがプロトコルであると広く配布したという事実にもかかわらず、この仮定を共有して、手広くインターネットを使用しません。 しかしながら、IETF共同体が、一般に、TCP/IPプロトコルとインターネットが大きいエンドユーザによる2つの全く異なったものになるように見られるとわかるのは、重要です。 すなわち、インターネットはいくつかのTCP/IP購買のための部分的なセールスポイントであるかもしれませんが、めったにそれは購買の大部分に関するプライマリ動機になりさえしません。 多くのエンドユーザには、事実上、かなり大きいTCP/IP展開が全くインターネットの接続性なしであります。 したがって、多くのエンドユーザが、せいぜい薄くなるようにインターネットとTCP/IPプロトコルとの関係を見ます。

   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.

より重要に、多くの会社が(非インターネット)へのかなりの投資を外部コミュニケーションインフラストラクチャにしました。 最近までインターネットが二国間条約から除かれたという事実と国際通商に必要な国際的な関税を含んでいて、さまざまな理由がこれを説明します。 どのような場合でも、今日のエンドユーザは彼らのビジネスプロセスをサポートするインターネットの(一般的な場合における)扶養家族ではありません。 [以下に注意してください。 直接彼らの仕事の責任を実現させるインターネットに依存しています前の文が、そんなに多くのFortune100従業員(作者などの)を否定しない: インターネットは多くの会社の「研究と教育」活動のための非常に貴重なツールになりました。 しかしながら、それは今日、直接会社の財政的な「結論」に影響する活動にめったに使用されません: 商業。] 対照的に、大規模な内部のTCP/IP展開の大きいエンドユーザは恐らく批判的に重要にそれらの会社の中核事業プロセスになるTCP/IP技術を見るかもしれません。

Fleischman                                                      [Page 3]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[3ページ]RFC1687

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.

Security諸島(すなわち、ファイアウォール)の重要性に関して大きいエンドユーザとIETFの別のコアの哲学的な差はあります。 一般的なIETF見解はSecurity諸島が「悪いもの」であるということです。 基本的なIETF仮定はそれらが設計しているアプリケーションが一般に必要であり、Security諸島が望ましくないフィルタをその用法に提供するということです。 一般に、すなわち、IETFには、データ・アクセスが無制限であって、広く利用可能であるべきであることを予想する世界観があります。

   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.

また、大きいエンドユーザは、彼らの従業員にはデータ・アクセスが必要とする相違があると信じている傾向があります: 工員には、飛行しているより異なるニーズを持っている会計士と異なったコンピューティングニーズがあります。科学者について研究するより異なるニーズを持っている技術者。 会社のネットワーク部は、それぞれのクラスの従業員が実際に彼らが必要とするサービスのタイプを受けるのを保証しようとします。 セキュリティ島は適切なサービスレベルが適切なクラスの従業員に提供されるかもしれないメカニズムの1つです、特に外部のアクセス能力に関して。

   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.

より重要に、会社の中に異なったクラスに関するコンピュータリソースがあります。 ある割合のこれらのリソースはその会社の継続する生存力に絶対に重要です。 これらのシステムは(かつて、)会社の外部から決してアクセスしやすいはずがありません。 実行可能なセキュリティー対策でこれらの「法人の宝石」を保護しなければなりません。セキュリティ島ははるかに大きい総合セキュリティソリューションの中の1つの非常に重要なコンポーネントです。

   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:

これらの理由で、私たちはヤコフRekhter(IBMの)によってされる観測とそれらの1994年1月28日の共同電子メールメッセージのボブ・マスコウィッツ(クライスラーの)と共に同意します。 彼らは書きました:

   "Hosts within sites that use IP can be partitioned into three
   categories:

「IPを使用するサイトの中のホストを3つのカテゴリに仕切ることができます」

    -    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."

- インターネット・アクセスを必要としないホスト。 - アプリケーションで扱うことができる限られたセットのインターネットのサービス(例えば、メール、FTP、ネットニュース、リモート・ログイン)へのアクセスを必要とするホストがリレーを層にします。 - 「インターネットへの無制限なアクセス(IPの接続性で、提供する)を必要とするホスト。」

Fleischman                                                      [Page 4]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[4ページ]RFC1687

   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".

多くの内部の要素に基づくその会社は独自に、会社がこれらの3つのクラスのデバイスの異なった需要を満たす正確なメカニズムを決定しなければなりません。 それぞれの独立しているソリューションは、その会社がどのようにそれら自身の「セキュリティ島」のバージョンを定義するかを決定するでしょう。

   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.

以下の5つの主要な特性が、ボーイングの環境について説明して、たぶん一般に他の大きいTCP/IP展開を代表しています。 作者は、大きいエンドユーザがどうIPngを見そうであるかに関する洞察を得るのに、これらの特性の理解が非常に重要であると信じています。

   1) Host Ratio

1) ホスト比

      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.

多くの会社が明らかに彼らのインターネットから直接アクセスしやすいTCP/IPホストの数を制限しようとします。 さまざまな理由(例えば、セキュリティ)でこれをします。 会社によってダイレクトインターネット・アクセス能力を持っているそれらのホスト対そのような能力のないそれらのホストの比率は異なるでしょうが、1:1000〜1:1万(さらに)まで及ぶ比率は並はずれていません。 このポイントの含意は世界的な(IPv4)インターネットアドレス空間の州が大企業の中で直接現在配布しているTCP/IPホストの小さい百分率に影響を与えるだけであるということです。 全体の人口が現在インターネット割り当てられたアドレスを使用していても、これは本当です。

   2) Router-to-Host Ratio

2) ルータからホストへの比

      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.

ほとんどの会社が彼らよりかなり多くのTCP/IPホストにIPルータを持たせます。 1〜100:600:1(さらに)の間で及ぶ比率は一般的です。 このポイントの含意は一般に、唯一ルータへの変化を要求する変遷アプローチがルータとホストの両方への変化を要求するアプローチよりあまり会社に破壊的でないということです。

Fleischman                                                      [Page 5]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[5ページ]RFC1687

   3) Business Factor

3) ビジネス要素

      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.

大企業は、ある他の飛行機、野球用バット、車、製品またはサービス提供の構造などの何らかのビジネス目的を実現させるために存在します。 コンピューティングは、より効率的に会社の企業目標を達成するためにビジネスプロセスを自動化するのを助ける不可欠のツールです。 オートメーションはアプリケーションで達成されます。 データ通信、オペレーティングシステム、およびコンピュータ・ハードウェアは目的を果たすのにアプリケーションで使用されるツールです。 したがって、ユーザは実際にネットワーク・テクノロジーではなく、アプリケーションを買います。 このポイントの主要な教訓がそれを使用するアプリケーションに従ってIPngが配布されるということであり、aが技術を改善するのはそれがあるからであるというわけではありません。

   4) Integration Factor

4) 統合要素

      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.

大企業は現在、多くのさまざまのコンピューティング環境をサポートします。 この多様性は、データ共有、アプリケーション相互運用性、「アプリケーションの移植性」、およびソフトウェアリユーザビリティを妨げることによって、会社のコンピューティング資産の有効性を制限します。 ネットの効果は、成長を妨げられたアプリケーションライフサイクルと増強されたサポートコストです。 データ通信はこの多様性を寄付するドメインの1つにすぎません。 例えば、ボーイング社は、現在、ネットワーク(例えば、TCP/IP、SNA、DECnet、OSI、IPX/SPX、AppleTalk、XNSなど)の中で少なくとも16の異なったプロトコルがファミリーであると配布しました。 それぞれの異なったプロトコルFamily人口は潜在的にユニークな訓練していて、管理のサポート、およびインフラストラクチャ要件を含意します。 その結果、企業目標は、ネットワークサポートコストを削減するためにさまざまのData CommunicationsプロトコルFamily展開を排除するか、または合併して、一緒に交信できるデバイスの数を増強するためにしばしば存在しています(すなわち、相互運用性を伸ばしてください)。 これは「さらに別のプロトコル」(YAP)を導入する可能性への基本的な憎悪をもたらします。 その結果、単に副産物がエンドユーザのコンピューティング資源とビジネスが目標であるとサポートするために、より多くの仕事、費用、およびリスクと結合された相互運用性への、より多くのバリケードであるので、完全に新しいセットのプロトコルを紹介するIPngソリューションは否定的に見られるでしょう。 これを言ったので、重要なエンドユーザ必要条件を満たすIPngを使用するアプリケーションなどの「酌量すべき事情」か広い(国際的な)商業サポートでこの憎悪が部分的に打ち勝たれるかもしれないのが観測されるべきです。

Fleischman                                                      [Page 6]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[6ページ]RFC1687

   5) Inertia Factor

5) 慣性要素

      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.

インターネットのIPv4アドレス空間の状態にかかわらず現在のIPプロトコル(IPv4)を使用し続ける生まれながらの傾向があります。 慣性をサポートする動機が以下を含んでいます: 既存のアプリケーションの依存(Application Programming Interface(API)の依存を含んでいます)。 追加議定書の複雑さの反対。 追加ハードウェア/ソフトウェア費用を制限する予算の規制。 追加アドレス管理と名前付けサービスコスト。 変遷コスト。 コストをサポートしてください。 トレーニングコスト。 など TCP/IPホストであると配布されたボーイングの数が、10万マークに向かって成長し続けているのに従って、この人口の慣性のパワーはますます強くなります。 しかしながら、単にシステムを変換するか、またはアップグレードさせる費用が保証されないので、慣性は、よりわずかな人口で存在してさえいます。 その結果、より古い「レガシーシステム」技術のポケットは特定の環境でしばしば存在しています(例えば、私たちはまだ古風なBSCプロトコルのポケットを持っています)。 このポイントの意味はIPng展開を正当化するために重要なビジネス利益がないと、経済学がそのような展開に反対するということです。 したがって、今度のIPngプロトコルが「究極の、そして、完全なプロトコル」であると判明しても、全体のIPv4人口はかつてIPngへの変遷がそうすると想像するのが非現実的です。 これは、私たちが私たちのネットワークの中でIPngを配布すると、私たちの内部のIPng展開が私たちの内部のIPv4共同体とコミュニケートできるという進行中の要件があることを意味します。 この要件は時間を持ち去りそうにはありません。

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?

したがって、大きい企業ユーザー見解からのIPngに関する中央の、そして、最終結果の質問は以下の通りです。 IPngを配布する費用を正当化する利益は何ですか?

   At this time we can conceive of only four possible causes which may
   motivate us to consider deploying IPng:

このとき、私たちはIPngを配布すると考えるために私たちを動機づけるかもしれない4つの考えられる原因しか想像できません:

   Possible Cause:                        Possible Corporate Response:

考えられる原因: 可能な法人の応答:

   1) Many Remote (external) Peers        Gateway external systems only.
      solely use IPng.

1) 多くのリモート(外部) 同輩ゲートウェイ外部のシステムだけ、唯一IPngを使用してください。

   2) Internet requires IPng usage.       Gateway external systems only.

2) インターネットはIPng用法を必要とします。 ゲートウェイ外的システム専用。

   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.

3) "Must have"製品はしっかりIPngと結合されていた状態でUpgradeインターナル法人です(例えば、「流れ」はリアルタイムのアプリケーションのためのどこをサポートIPngにネットワークでつなぐか)。その機能性が必要です。

Fleischman                                                      [Page 7]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[7ページ]RFC1687

   4) Senior management directs IPng      Respond appropriately.
      usage.

4) 経営幹部は適切にIPng Respondを指示します。. 用法。

   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.

明らかに、インターネット共同体がIPng(すなわち、インターネットの上のIPv4のスケーラビリティ)を作成するのを強制している理由が自分たちでユーザがそれら自身の私設のネットワークの中でIPngを配布する適切な動機でないことに注意するべきではありません。 すなわち、この命令へのありえそうな応答はIPng用法がインターネット用法のための前提条件として強制されるようになるなら、IPngからIPv4への応用層ゲートウェイになる外部のアクセス能力がある私たちのわずかなホストしか変換しないだろうことです。 これは私たちの広大な内部のTCP/IPの残りを展開に変わりがないままにするでしょう。 その結果、外部のアクセスのためのゲートウェイを考えて、会社の内部のネットワークがIPngをサポートする少ない動機があるかもしれません。

User's IPv4 "Itches" Needing Scratching

引っ掻くのが必要でありながら、ユーザのIPv4は「かゆみを起こします」。

   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:

すべてが既存のTCP/IP展開によって必ず「完全であり」、したがって、改良されたIPv4ネットワーク層(IPng)が「引っ掻くことができない」「かゆみ」が全くないことを意味するためにIPv4へのエンドユーザの「忠誠」を解釈するべきではありません。 このセクションの目的は多くのエンドユーザに非常に厄介な問題のいくつかを扱うことです:

   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.

a) セキュリティ。 TCP/IPプロトコルは電波媒体(例えば、イーサネットバージョン2)で一般的に配布されます。 しかしながら、パスワードを暗号化するTCP/IPメカニズムかこのメディアを横断するデータが不十分です。 これは迅速に決議される必要がある非常に重大な問題です。 統合していて有効なTCP/IPセキュリティー体系は、定義されて、すべてのベンダーのTCP/IP製品の向こう側に広く実装されるようになる必要があります。

   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

B) ユーザAddress Spaceプライバシー。 現在のIPv4ネットワークアドレシング方針は、エンドユーザがそれら自身の内部のネットワークにおける使用のIPネットワーク・ナンバーを得に外部実体に行くのを必要とします。 これらの外部実体には、これらのネットワーク要求が「有効である」か否かに関係なく、決定する傲慢があります。 それはそれらが他のものに影響するかもしれない特定のインスタンス以外の会社の内部のアドレシング方針がそれら自身の個人的な問題であるという私たちの信念です。 その結果、本当の必要性は2つのクラスのIPv4ネットワーク・ナンバーのために存在しています: 今日(理論的に)インターネットに目に見えるもの(そして、その結果、外部の要件を受けることがある)とインターネットに決して関連づけられないもの(そして、その結果、厳密に個人的です)。 私たちは、「ローカルのアドレス」の概念が執事の不十分なグローバル資源へのインターネットの正当な必要性とプライバシーの法人の必要性の間の実行可能な感染であると信じています。 「ローカルのアドレス」が定義上そうである、非グローバルにユニークである、そうするべきであるアドレス

Fleischman                                                      [Page 8]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[8ページ]RFC1687

       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).

私たちは、16隣接のClass B「ローカルのアドレス」が、すぐに内部の法人の用法に利用可能に作られる必要であると信じています。 また、そのような有用性は新しいIPv4ネットワーク・ナンバーの長期の需要を抑えるかもしれません(RFC1597を見てください)。

   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.

C) 自己に、ネットワークを定義します。 プラグアンドプレイTCP/IPがどれをネットワークでつなぐかので大きいエンドユーザにはa差し迫った必要性がある、自動構成、自動アドレスと、自動レジスタです。 エンドユーザは繰り返して、私たちが現在の手話教授法を働かせることができないこと(すなわち、人為ミスのための重刑)を示しました。 私たちは、既存のDHCP技術がこの方向への良いスタートであると信じています。

   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.

D) APIとネットワーク集積。 エンドユーザは多くの異なった複雑なプロトコルファミリーを配布しました。 私たちは、これらのさまざまの展開が実行可能な変遷ツールと共に統合するように一緒になるかもしれないツールが移行する必要があります。TCP/IPベースのソリューションへの独占代替手段。 また、私たちは、製品が「開いている」マルチベンダを使用することを望んでいます、マルチプラットフォーム、この統合取り組みで支援するために通信規約「ファミリー」といういくつかのデータの向こう側にサポートされる暴露しているApplication Programming Interfaces(API)。

   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.

E) 国際通商。 一般に、エンドユーザは、私たちのビジネス要件を満たすためには今日、国際通商にどんな範囲に関して一般にTCP/IPを使用できるか、そして、これが費用対効果に優れて「安全な」オプションであるかどうか不確かです。

   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).

F) 技術的進歩。 私たちには、既存の技術を絶え間ない「押すこと」を要求する進行中のアプリケーションの必要性があります。 このうち、必要性は以下への実行可能な(例えば、私たちの現在のインフラストラクチャへの統合可能)ソリューションです: モバイルホスト、マルチメディア応用、リアルタイムのアプリケーション(まさしくその高帯域幅アプリケーション)はまさしくその低バンド幅(例えば基づくラジオ)アプリケーションを改良しました、標準のTCP/IPベースのトランザクション処理アプリケーション(例えば、マルチベンダ分散データベース)。

   Only Two Motivations For Users To Deploy IPng

ユーザがIPngを配布する2つの動機だけ

   Despite this list of IPv4 problem areas, we suspect that there are
   only two causes which may motivate users to widely deploy IPng:

IPv4問題領域のこのリストにもかかわらず、私たちは、広くIPngを配布するためにユーザを動機づけるかもしれない2つの原因しかないと疑います:

      (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.

(1) IPng製品がIPv4が提供できない重要な機能性(例えば、リアルタイムのアプリケーション、マルチメディア応用、本物(スケーラブルな)のプラグアンドプレイネットワークなど)を加えるなら、ユーザは、その機能性が必要であるIPngを配布するために動機づけられるでしょう。

Fleischman                                                      [Page 9]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[9ページ]RFC1687

      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.

しかしながら、これらの展開は以前に説明される「統合要素」と「慣性要素」力と戦わなければなりません。 これは、そのような展開を正当化するために重要なビジネス利得があるに違いないのを含意します。 この闘争がちょうどどう「終えられるだろうか」を予測するのが不可能ですが、そのIPngがたぶん配布されると仮定するのがそれは妥当である、「」 方針だけを必要とするので。 最適に、変化であるとローカライズされたこれらの影響からネットワークの残りを保護するために特定の方法を取るでしょう。 もちろん、「キラー・アプリケーション」(すなわち、かなり多くの主要なビジネスプロセスに非常に重要なアプリケーション)に応じて、IPngは添付されるようになるはずであり、次に、すべての賭けが以下にあります。 IPngは広く配布されるようになるでしょう。 しかしながら、また、ほとんどすべての(初期)のIPngアプリケーションがそれらがたまたま「キラー・アプリケーション」でないなら単に彼らが危険を表すので配布している、かなり増強された展開であり、エンドユーザのためにコストをサポートするために重要なハードルに打ち勝たなければならないと認められるべきです。

      (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:

(2) IPngがインターネットStandardsと国際Standards(すなわち、OSI)の間の集合を伸ばしているなら、この集合はIPngの運命を変えるかもしれません。 すなわち、多くの大企業のネットワークは現在、強い、しかし、相容れない要件のセットによって運転されています: 1つは、インターネットStandards(すなわち、TCP/IP)ともう1セットが国際Standardsと共に服従を要求していて服従を要求しながら、セットしました。 この紙は、読者が既にエンドユーザがインターネットStandardsを配布して、使用しようとする多くの理由に詳しいと仮定します。 ↓これはエンドユーザがまた、国際Standards(すなわち、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
       (i.e., OSI) are the only government-sanctioned method for
       commercial data communications.  Aspects of this picture are
       currently in the process of changing.

a) 世界的な商業はそれらの条約と法的な協定通りに政府によって規制されます。 世界的なテレコミュニケーションはITU(国連の貸し切りの、または、認可された組織)によって規制されます。 国際Standards(すなわち、OSI)は商業的データコミュニケーションのための唯一の政府によって認可されたメソッドです。 現在、この画像の局面が変化の途中にあります。

   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:

B) 現在独占である飛行世界的な空対地の、そして、地対地のコミュニケーションをOSIベースの(CLNP)に取り替えています。 築き上げられて、:多くの異なった国家的、そして、国際的なフォーラムで築き上げられている飛行Telecommunications Network(ATN)インターネット

       *  International Civil Aviation Organization (ICAO)
       *  International Air Transport Association (IATA)
       *  Airlines Electronic Engineering Committee (AEEC)

* 国際民間航空機関(ICAO)*国際航空運送協会(IATA)*航空会社電子工学委員会(AEEC)

Fleischman                                                     [Page 10]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[10ページ]RFC1687

       "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.]

「民間Aviation Authorities、航空会社、および自家用機はデータ通信量の2つの大範疇をそれらのコンピュータに伝えるのにATNを使用するでしょう」 「トラフィックサービスコミュニケーション(ATSC)と飛行産業サービスコミュニケーション(AISC)を放送してください。」 [注意: エアライン乗客のデータ通信は指示で扱われません。]

   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:

C) 会社の顧客はそれらがどれを操作する政府で徴収されるデータ通信要件をそれらに持つかもしれません。それらは、彼らの顧客のニーズを実現させるためにそれら自身ので順番に製品を支えなければなりません。 例えば、存在することによって、ボーイングは影響を及ぼされます:

       * 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.

* コンピュータAided Logistics Support、(カルス、;、すなわち、これらがGOSIP(OSI)ベースである )、米国国防総省の契約者のための要件。 * 上でAとBから発するエアライン要件。

   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.

D) 私たちがいったん次に強制されない国際Standardsを配布すると外部の要素で別の技術に移行するエンドユーザ知覚。 したがって、私たちには、増強された顧客満足や、ビジネスプロセス流れ時間改良や、レガシーシステム近代化や、コスト回避などの私たちの本当のコンピューティング問題に集結する「安全な」基礎があるでしょう。

   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.

E) 政府と共に契約法を得ることを望んでいる実体の提案は多くの主観的で客観的なベースの上で評価されます。 主観的な問題の1つは、法人の同じ意見のような無形財産を含む入札者会社の「責任」とたぶん「信頼性」でしょう。 この理由で、入札者には、また、会社の方針が同様の規格を含んでいるなら、政府にそれらの公式の規格としてOSIがある限り、主観的な利点があるかもしれません、特にデータ通信が交渉されているなら。

   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.

F) 戦略のエンドユーザが代替であったなら、そのIPv4は不適任ですIPngの必要性がそうする知覚が、含意する。 また、このとき、IPngは実行可能な展開オプションではありません。

   G)  Doubts concerning IPv4 scalability (e.g., toasternet: an
       algorithmic change in which currently "dumb devices" become
       intelligent and suddenly require Internet connectivity).

G) IPv4スケーラビリティに関する疑問、(例えば、toasternet: 現在の「馬鹿なデバイス」が知的になって、突然インターネットの接続性を必要とするアルゴリズムの変化)

   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

現在、これらの「OSI動機」の多くをこのとき変化させているように見えます。 関心をもってこの可能性を追跡しなければなりません。 しかしながら、このセクションの要所はそのaです。

Fleischman                                                     [Page 11]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[11ページ]RFC1687

   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.

したがって、インターネットStandardsと国際Standardsの間の、よりすごい相乗作用(統合/採用)を達成するのを手段を見つけることができるなら、企業経営は合併している規格の内部の展開を強制して、彼らの外部の使用を促進する傾向があるかもしれません。 最適に、そのような相乗作用は現在プロトコルの多様性(すなわち、「統合要素」が力であるとサポートする)であると配布されている減少の約束を提供するべきです。 この集合が達成される特定のメソッドによって、また、以前に言及された「慣性要素」力を部分的に相殺するかもしれません、特にIPngが、既に配布されたプロトコルであると判明するなら。

User-based IPng Requirements

ユーザベースのIPng要件

   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.

上記では、人は、インターネットの上で交信するのにIPngを使用する命令が一般に、大きい企業ネットワークがそれらのネットワークの中でIPngをサポートする必要性を対応する含意しないのを見ることができます。 したがって、IPv4スケーラビリティ制限は特定のIPv4交換プロトコルをインターネットに特定するやむにやまれない理由ですが、他の要素は私設の企業ネットワークの中で仕事しています。 これらの要素は、大きいTCP/IPエンドユーザにはIPng製品が一般に、利用可能になった後にさえIPv4製品を購入する継続する必要があるのを含意します。

   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:

しかしながら、IETF共同体が活発にIPngソリューションを特定するのに従事しているので、ソリューションができるだけ多くのエンドユーザ需要を満たすのは、望ましいです。 この理由で、↓これがどんなIPngソリューションのための重要な「ユーザ要件」であるとも思います:

   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.

1) IPngアプローチは、ユーザがばらばらのファッションでIPngにゆっくり移行することを許可しなければなりません。 IPngが広く配布されるようになっても、ユーザが大規模なIPv4のすべてがインストールした変遷にIPngへのベースを望んでいると予想するのは非現実的です。 その結果、アプローチは世界的なインターネットの要件にかかわらずIPngホストとIPv4ホストとの法人に内部のコミュニケーションを無期限にサポートしなければなりません。

   2)  The IPng approach must not hinder technological advances from
       being implemented.

2) IPngアプローチは、技術的進歩が実装されるのを妨げてはいけません。

   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

3) IPngアプローチが結局インターネットStandardsと国際Standards(すなわち、OSI)の間の、よりすごい相乗作用(統合/採用)を伸ばすと予想されます。 [注意: これはインターネットを持っているのを含むさまざまな方法で達成されるかもしれません。

Fleischman                                                     [Page 12]

RFC 1687         A Large Corporate User's View of IPng       August 1994

大きい企業ユーザーのものが1994年8月にIPngについて見るフライシュマン[12ページ]RFC1687

       Standards adopted as International Standards or else having the
       International Standards adopted as Internet Standards.]

国際Standardsとして採用されるか、または国際Standardsを持っている規格がインターネットとして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.

4) IPngアプローチには、「自己を定義するネットワーク」(すなわち、「働いて、プレーする」)能力があるべきです。 すなわち、大きいインストールで、人の企業ネットワークの中で容易にデバイスを動かすかもしれないデバイスの移植性を必要として、それらは、autoaddress、新しい位置の明白な人間の管理オーバーヘッドのないautoregisterなど--それが新しい位置のセキュリティ評価基準であると仮定して、会われたように自動構成します。

   5)  The approach must have network security characteristics which are
       better than existing IPv4 protocols.

5) アプローチには、既存のIPv4プロトコルより良いネットワークセキュリティの特性がなければなりません。

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.

概要、意志が決定する主要因、--、何という範囲--IPngによる配布されて、大きいエンドユーザがIPngが私たちのビジネスによって批判的に必要とされるアプリケーションの工事のための必須元素になるかどうかということであるということであるだろうか。 IPngが重要なビジネス需要を満たすアプリケーションで添付されると、それは配布されるでしょう。 そうでないなら、それはほとんど大きいエンドユーザへの関連性のものではありません。 IPngに起こることにかかわらず、大量のIPv4デバイスがIPv4製品の継続的な開発が確実にIPv4が予見できる未来の重要なプロトコルのままで残って、賢明になるようにするでしょう。

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

エリックフライシュマンネットワーク建築家ボーイングコンピュータが私書箱24346、MSを修理する、7M、-、ハ、ワシントン98124-0346シアトル(米国)

   EMail:  ericf@atc.boeing.com

メール: ericf@atc.boeing.com

Fleischman                                                     [Page 13]

フライシュマン[13ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

border-top-style 上ボーダーのスタイルを指定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る