RFC1678 日本語訳

Network Working Group                                         E. Britton
Request for Comments: 1678                                       J. Tavs
Category: Informational                                              IBM
                                                             August 1994

コメントを求めるワーキンググループE.ブリトン要求をネットワークでつないでください: 1678年のJ.Tavsカテゴリ: 情報のIBM1994年8月

             IPng Requirements of Large Corporate Networks

大きい企業ネットワークの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.  This draft
   summarizes some of the requirements of large corporate networks for
   the next generation of the Internet protcol suite.

RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。 この草稿はインターネットprotcolスイートの次世代のために大きい企業ネットワークの要件のいくつかをまとめます。

Executive Overview

幹部社員概要

   As more and more corporations are using TCP/IP for their mission-
   critical applications, they are bringing additional requirements,
   summarized below, the satisfaction of which would make TCP/IP even
   more appealing to businesses.  Since these are requirements rather
   than solutions, we include capabilities that might be provided in
   protocol layers other than the one that IPv4 occupies; i.e., these
   items might lie outside the scope typically envisioned for IPng, but
   we'll refer to them as IPng requirements nonetheless.  When we
   mention potential solutions, it is not to suggest that they are the
   best approach, but merely to clarify the requirement.

ますます多くの会社が彼らの任務の重要なアプリケーションにTCP/IPを使用しているとき、それらは以下へまとめられたそれの満足がビジネスにさらに求めながらTCP/IPを作りさえする追加要件をもたらしています。 これらがソリューションよりむしろ要件であるので、私たちはIPv4が占領するもの以外のプロトコル層で提供されるかもしれない能力を入れます。 範囲の外にすなわち、これらの項目がIPngのために通常思い描かれた状態であるかもしれませんが、私たちはそれにもかかわらず、IPng要件とそれらを呼ぶつもりです。 私たちが潜在的ソリューションについて言及するとき、それらが最も良いアプローチであると示唆するのではなく、それは単に要件をはっきりさせることになっています。

   Among business users the major requirements we see for IPng are:

産業使用者の中では、私たちがIPngに関して見る主要な要件は以下の通りです。

      -- smooth migration from, and coexistence with, IPv4;
      -- predictable levels of service for predictable costs;
      -- security; and
      -- accommodation of multiple protocols suites.

-- 移行を整える、共存、IPv4。 -- 予測できるコストのための予測できるレベルのサービス。 -- セキュリティ。 そして、--複数のプロトコルスイートの宿泊設備。

   We also mention several more specific requirements.

また、私たちはいくつかの、より特定の要件について言及します。

   IPng must have a viable strategy for migration from, and coexistence
   with, IPv4.  IPv4 and IPng must coexist well, because they will need
   to do so for several years.  To encourage IPv4 users to upgrade to

IPngには移行のためのa実行可能な戦略がなければならない、共存、IPv4。 彼らが、数年間そうする必要があるので、IPv4とIPngはよく共存しなければなりません。 アップグレードするIPv4ユーザを奨励するために

Britton & Tavs                                                  [Page 1]

RFC 1678     IPng Requirements of Large Corporate Networks   August 1994

大きい企業ネットワーク1994年8月のブリトンとTavs[1ページ]RFC1678IPng要件

   IPng, IPng must offer compelling advantages and an easy migration
   path.

IPng、IPngは無視できない利点と簡単な移行パスを示さなければなりません。

   Corporate networks must meet promised levels of service while
   controlling costs through efficient use of resources.  The IETF
   should consider both technical solutions (such as service classes and
   priorities) and administrative ones (such as accounting) to promote
   economy.

企業ネットワークはリソースの効率的な使用でコストを制御している間、約束のレベルのサービスを満たさなければなりません。 IETFは、技術的解決法(サービスのクラスやプライオリティなどの)と管理もの(会計などの)の両方が経済を促進すると考えるはずです。

   Many businesses will not connect to a network until they are
   confident that it will not significantly threaten the
   confidentiality, integrity, or availability of their data.

彼らがそれらのデータの秘密性、保全、または有用性をかなり脅かさないと確信するまで、多くのビジネスはネットワークに接続しないでしょう。

   Corporations tend to use multiple protocols.  Numerous forces stymie
   the desire to settle on just one protocol for a large corporation:
   diverse installed bases, skills, technical factors, and the general
   trend toward corporate decentralization.  The IETF needs a strategy
   for heterogeneity flexible enough to accommodate the principal
   multiprotocol techniques, including multiprotocol transport,
   tunneling, and link sharing.

社は、複数のプロトコルを使用する傾向があります。 多数の力は大企業のためにちょうど1つのプロトコルについて決める願望を邪魔します: さまざまのインストールされたベース、技能、技術的な要素、および司令官は法人の分散に向かって傾きます。 十分フレキシブルな異種性が主要な「マルチ-プロトコル」のテクニックに対応するように、IETFは戦略を必要とします、「マルチ-プロトコル」輸送、トンネリング、およびリンク共有を含んでいて。

   Some of these requirements might be satisfied by more extensive
   deployment of existing Internet architectures (e.g., Generic Security
   Service and IPv4 type of service).  The current Internet protocols
   could be enhanced to satisfy most of the remaining requirements of
   commercial users while retaining IPv4.  Nevertheless, some
   corporations will be scared away from TCP/IP by the publicity about
   the address space until the IETF sets a direction for its expansion.

これらの要件のいくつかが既存のインターネットアーキテクチャ(サービスの例えば、Generic Security ServiceとIPv4タイプ)の、より大規模な展開で満たされるかもしれません。 IPv4を保有している間、営利的ユーザの残っている要件の大部分を満たすために現在のインターネットプロトコルを高めることができました。 それにもかかわらず、IETFが拡張のための方向を設定するまで、いくつかの会社が遠くでアドレス空間に関してTCP/IPから宣伝におびえるようになるでしょう。

Migration and Coexistence

移行と共存

   As the use of IPv4 continues to grow, the day may come when no more
   IPv4 network addresses will be left, and no additional networks will
   be able to connect to the Internet.  Classless Inter-Domain Routing
   (CIDR, RFC 1519) and careful gleaning of the address space will
   postpone that cutoff for several years.  The hundreds of millions of
   people on networks that do get IPv4 addresses won't be affected
   directly by the exhaustion of the address space, but they will miss
   the opportunity to communicate with those less lucky.

それ以上のIPv4ネットワーク・アドレスが全く残されないで、どんな追加ネットワークもインターネットに接続できないとき、IPv4の使用が、成長し続けているのに従って、1日は来るかもしれません。 アドレス空間の階級のないInter-ドメインルート設定(CIDR、RFC1519)と慎重な落ち穂拾いは数年間その締切りを延期するでしょう。 IPv4を手に入れるネットワークの人々では、何百もの数百万、アドレスは直接アドレス空間の疲労困憊で影響を受けないでしょうが、それらは幸運なそれらが、より少ない状態で交信する機会を逃すでしょう。

   Because the Internet is too large for all its users to cutover to
   IPng quickly, IPng must coexist well with IPv4.  Furthermore, IPv4
   users won't upgrade to IPng without a compelling reason.  Access to
   new services will not be a strong motivation, since new services will
   want to support both the IPng users and the IPv4 users.  Only
   services that cannot exist on IPv4 will be willing to use IPng
   exclusively.  Moreover, if IPng requires more resources (e.g.,
   storage, memory, or administrative complexity) than IPv4, users will

すべてのユーザには、インターネットがIPngへのカットオーバにすぐに大き過ぎるので、IPngはIPv4とよく共存しなければなりません。 その上、IPv4ユーザはやむにやまれない理由なしでIPngにアップグレードしないでしょう。 新種業務へのアクセスは強い動機づけのようにならないでしょう、新種業務が、両方がIPngユーザとIPv4ユーザであるとサポートしたくなるので。 IPv4に存在できないサービスだけが、排他的にIPngを使用しても構わないと思うでしょう。 そのうえ、IPngがIPv4より多くのリソース(例えば、ストレージ、メモリ、または管理複雑さ)を必要とするなら、ユーザは必要になるでしょう。

Britton & Tavs                                                  [Page 2]

RFC 1678     IPng Requirements of Large Corporate Networks   August 1994

大きい企業ネットワーク1994年8月のブリトンとTavs[2ページ]RFC1678IPng要件

   not install IPng unless it has clear benefits over IPv4.  Indeed, the
   millions of users of low-end systems (DOS, sub-notebooks) might not
   ever be able to use IPng if it takes more memory.  Thus there will be
   a long period of coexistence between IPng and IPv4, so the
   coexistence needs to be quite painless, and not based on any
   assumption that IPv4 use will diminish quickly.

IPv4の上に明確な利益を持っていない場合、IPngをインストールしてください。 本当に、より多くのメモリを取るなら、ローエンドシステム(DOS、サブノートブック)の何百万人ものユーザはIPngを使用できないかもしれません。 したがって、IPngとIPv4の間には、長期の共存があるので、共存は、IPv4使用が急速に減少するというどんな前提にもかなり無痛であって、基づかない必要があります。

Service Level Agreements

サービス・レベル・アグリーメント

   If a corporation depends on its network for applications that are
   critical to its business (such as airlines do for reservations, and
   brokerages do for stock and bond trades), then the corporation
   insists that the network provide the needed service level for a
   predictable cost, so they can allow for it in their budget ahead of
   time.  A service level agreement (SLA) is a contract between
   network's provider and users that defines the service level which a
   user will see and the cost associated with that level of service.
   Measurements in an SLA may include response times (average and
   maximum), availability percentages, number of active sessions,
   throughput rates, etc..  Businesses need to be able to predict and
   guarantee the service levels and costs (routing capacity, link
   bandwidth, etc.) for their traffic patterns on a TCP/IP network.

会社がビジネスに重要なアプリケーションのためにネットワークによるなら(航空会社が予約、および仲買業がそうするのでストックでして、接着されるとき、そのようなものは取り引きされます)会社が、ネットワークが必要なサービスレベルを予測できる費用に提供すると主張するので、彼らは早めに、自分達の予算でそれを考慮できます。 サービスレベル協定(SLA)はネットワークのプロバイダーとユーザとのユーザが見るサービスレベルとそのレベルのサービスに関連している費用を定義する契約です。 SLAにおける測定値は応答時間(平均して最大の)、有用性割合、活発なセッションの数、押出量などを含むかもしれません。 ビジネスは、TCP/IPネットワークに関するそれらのトラフィック・パターンのために、サービスレベルとコスト(ルーティング容量、リンク帯域幅など)を予測して、保証できる必要があります。

   IPng should allow control of the cost of networking, a major concern
   for corporations.  Teleprocessing lines are a significant cost in
   corporate networks.  Although the cost per bit-per-second tends to be
   lower on higher-bandwidth links, high-bandwidth links can be hard to
   get, particularly in emerging nations. In many places it is difficult
   to acquire a 64 kpbs line, and T1 service might not exist.
   Furthermore, lead times can be over six months.  Even in the US the
   cost of transcontinental T1 service is high enough to encourage high
   utilization.  Cost-conscious businesses want IPng to allow high
   utilization of teleprocessing links, but without requiring excessive
   processing power to achieve the high utilization.  There has been
   considerable speculation concerning the goodput through congested
   routes when using the Internet's current congestion control
   algorithms; instead, it should be measured in a range of realistic
   cases.  If peak-busy-hour goodput under congestion is near the
   theoretical maximum, publicize the data and move on to other
   requirements.  If not, then the IETF should seek a better standard
   (e.g., they might explore XTP's adaptive rate-based approach and
   other proposals).

IPngはネットワークの費用、会社に関する主要な関心事のコントロールを許すはずです。 遠隔処理系列は企業ネットワークで多大な費用です。 1ビット/秒あたりの費用は、より高い帯域幅リンクで低い傾向がありますが、高帯域リンクは得るのが困難である場合があります、特に新興国家で。 多くの場所では、64kpbs系列を取得するのが難しく、T1サービスは存在しないかもしれません。 その上、先行時間は6カ月以上であるかもしれません。 米国でさえ、大陸横断のT1サービスの費用は高使用率を奨励できるくらい高いです。 高使用率を達成するために過度の処理能力を必要としないで、IPngに遠隔処理リンクの高使用率を許容して欲しいのですが、コスト意識が高いビジネスはそうします。 インターネットの現在の輻輳制御アルゴリズムを使用するとき、goodputに関してかなりの思惑が混雑しているルートでありました。 代わりに、それはさまざまな現実的な場合で測定されるべきです。 ほぼ理論上の最大に混雑している忙しい時間に最大限にしているgoodputがあるなら、データについてピーアールしてください、そして、他の要件に移行してください。 そうでなければ、そして、IETFは、より良い規格を求めるはずです(例えば、彼らはXTPの適応型のレートベースのアプローチと他の提案を探るかもしれません)。

   Functions, such as class of service and priority, that let an
   enterprise control use of bandwidth also may help meet service level
   agreements.  On the one hand, it has been said that the absence of
   these inhibits TCP/IP usage in corporate networks, especially when
   predictable interactive response times are required.  On the other

企業が帯域幅の使用を制御するサービスと優先権のクラスなどの関数も、サービスレベル協定を満たすのを助けるかもしれません。 一方では、これらの不在が企業ネットワークでTCP/IP用法を禁止すると言われています、特に予測できる対話的な応答時間が必要であるときに。 もう片方に関して

Britton & Tavs                                                  [Page 3]

RFC 1678     IPng Requirements of Large Corporate Networks   August 1994

大きい企業ネットワーク1994年8月のブリトンとTavs[3ページ]RFC1678IPng要件

   hand, few vendors have felt motivated to implement TCP's architected
   type-of-service, and priority tends to be handled in a non-standard
   way (e.g., to assure that interactive well-known ports, such as
   Telnet, get faster response times than non-interactive well-known
   ports, such as file transfer).  The IETF should sort out these
   apparently conflicting perspectives.  If the ad hoc techniques can be
   demonstrated to be adequate, then they should be standardized;
   otherwise, effective techniques should be developed and standardized.

手で、わずかなベンダーしかTCPのarchitectedサービスのタイプを実装するために動機づけられているのは感じられていません、そして、優先権は標準的でない方法(例えばTelnetなどの対話的なウェルノウンポートがファイル転送などの非対話的なウェルノウンポートより速い応答時間を得ることを保証する)で扱われる傾向があります。 IETFはこれらの明らかに闘争している見解を整理するはずです。 適切になるように臨時のテクニックを示すことができるなら、それらは標準化されるべきです。 さもなければ、効果的な技術は、見いだされて、標準化されるべきです。

   Commercial users often require the options of a higher level of
   service for a higher cost, or a lower level of service for a lower
   cost; e.g., some businesses pay top dollar to assure fast response
   time during business hours, but choose less expensive satellite
   services for data backup during the night.  Pervasive use of IPv4's
   type-of-service markings might satisfy this requirement.

営利的ユーザはしばしばより高い費用のための、より高いレベルのサービスのオプション、または低い費用のためのサービスの下のレベルを必要とします。 例えばいくつかのビジネスが、最高額が営業時間の間速い応答時間を保証しますが、夜データバックアップには、それほど高価でない衛星サービスを選ぶのを支払います。 IPv4の標記のタイプの広範囲な使用はこの要件を満たすかもしれません。

   To discourage waste of bandwidth and other expensive resources,
   corporations want to account for their use.  Direct cost recovery
   would let an entity measure and benchmark its efficiency with minimal
   economic distortion.  Alternatives, such as placing these costs into
   corporate overhead or charging per connection, make sense when the
   administrative cost of implementing usage-based accounting is high
   enough to introduce more economic distortion than the alternatives
   would.  For example, connection-based costs alone may be adequate for
   a resource (such as LAN bandwidth) that is not scarce or expensive,
   but a combination of a connection cost and a usage cost may be more
   appropriate for a more scarce  or expensive resource (such as WAN
   bandwidth).  Balance must be maintained between the overhead of
   accounting and the granularity of cost allocation.

帯域幅の浪費と他の高価なリソースに水をさしているために、会社は彼らの使用を説明したがっています。 直接費回復は実体を測定するでしょう、そして、ベンチマークは最小量の経済ひずみに従った効率を測定します。 用法ベースの会計を実装する管理費が代替手段がそうするだろうより経済のひずみを導入できるくらい高いときに、これらのコストを法人のオーバーヘッドに置くか、または接続単位で充電などなどの代替手段は理解できます。 例えば、不十分でもなくて、また高価でもないリソース(LAN帯域幅などの)に、接続ベースのコストだけが適切であるかもしれませんが、不十分であるか高価なリソース(WAN帯域幅などの)には、費用と用法がかかる接続の組み合わせは、より適切であるかもしれません。 会計のオーバーヘッドと費用配分の粒状の間でバランスを維持しなければなりません。

Security

セキュリティ

   Many corporations will stick with their private networks until public
   ones can guarantee equivalent confidentiality, integrity, and
   availability.  It is not clear that additional architecture is needed
   to satisfy this requirement;  perhaps more wide spread use of
   existing security technology would suffice.  For example, the
   Internet could encourage wide deployment of Generic Security Service,
   and then solicit feedback on whether additional security requirements
   need to be satisfied.  Note that businesses are so concerned about
   network cost control mechanisms that they want them secured against
   tampering.  IPng should not interfere with firewalls, which many
   corporations consider essential.

公共のものが同等な秘密性、保全、および有用性を保証できるまで、多くの会社がそれらの私設のネットワークに忠実でしょう。 追加アーキテクチャがこの要件を満たすのに必要であるのは、明確ではありません。 恐らく、既存のセキュリティー技術の、より広い普及の使用は十分でしょう。 例えば、インターネットは、Generic Security Serviceの広い展開を奨励して、次に、追加担保要件が、満たされる必要があるかどうかに関するフィードバックに請求するかもしれません。 ビジネスがネットワーク経費節減メカニズムに関して非常に心配して、彼らが改ざんに対してそれらを機密保護して欲しいことに注意してください。 IPngはファイアウォールを妨げるはずがありません。(多くの会社が不可欠であるとファイアウォールが考えます)。

Britton & Tavs                                                  [Page 4]

RFC 1678     IPng Requirements of Large Corporate Networks   August 1994

大きい企業ネットワーク1994年8月のブリトンとTavs[4ページ]RFC1678IPng要件

Heterogeneity

異種性

   Corporate users want the Internet to accommodate multiple protocol
   suites.  Several different protocol suites are growing in use, and
   some older ones will be used for many more years.  Although many
   people wish there were only one protocol in the world, there is
   little agreement on which one it should be.

企業ユーザーは、インターネットに複数のプロトコル群を収容して欲しいです。 いくつかの異なったプロトコル群が使用中であり発展しています、そして、いくつかの、より古いものがずっと多くの数年間使用されるでしょう。 多くの人々が、1つのプロトコルしか世界にないことを願っていますが、それがそうであるべきである協定がほとんどありません。

   Since the marketplace has not settled on one approach to handling
   multiple protocols, IPng should be flexible enough to accommodate a
   variety of technical approaches to achieving heterogeneity.  For
   example, most networking protocols assume they will be the dominate
   protocol that transports all others;  protocol designers should pay
   more attention to making their protocols easily transported by
   others.  IPng needs to be flexible enough to accommodate the major
   multiprotocol trends, including multiprotocol transport networking
   (for an example, see X/OPEN document G306), tunneling (both IP being
   the tunnel and being tunneled), and link sharing (e.g., point-to-
   point protocol and frame relay).  Fair sharing of bandwidth by
   protocols with different congestion control mechanisms is a
   particularly interesting subject.

市場が複数のプロトコルを扱うことへの1つのアプローチについて決めていないので、IPngは異種性を達成することへのさまざまな技術的なアプローチを収容するほどフレキシブルであるべきです。 例えば、ほとんどのネットワーク・プロトコルが、それらがそうになると仮定する、すべての他のものを輸送するプロトコルを支配してください。 プロトコルデザイナーは他のものによる彼らのプロトコルを容易に輸送させることに関する、より多くの注意を向けるべきです。 IPngは「マルチ-プロトコル」輸送ネットワークを含んでいて(例に関して、X/オープンドキュメントG306を見てください)、(トンネルであるIPとトンネルを堀られる両方)にトンネルを堀って、主要な「マルチ-プロトコル」傾向を収容するほどフレキシブルであり、共有をリンクする必要があります(例えば、ポイントからポイントへのプロトコルとフレームリレー)。 異なった混雑制御機構があるプロトコルによる帯域幅の公正な共有は特におもしろい対象です。

Flow and Resource Reservation

流れと資源予約

   Corporate users are becoming more interested in transmitting both
   non-isochronous and isochronous information together across the same
   link.  IPng should coexist effectively with the isochronous protocols
   being developed for the Internet.

企業ユーザーは非同一時間の、そして、同一時間の両方の情報を同じリンクの反対側に一緒に伝えるのにより関心を持つようになっています。 IPngは有効にインターネットに開発される同一時間のプロトコルに共存するはずです。

   The Internet protocols should take advantage of services that may be
   offered by an underlying fast packet switching service. Constant-
   bit-rate and variable-bit-rate services typically require
   specification of, and conformance to, traffic descriptors and
   specification of quality-of-service objectives from applications or
   users.  The Internet's isochronous protocols should provide
   mechanisms to take advantage of multimedia services that will be
   offered by fast packet switching networks, and must ensure that
   quality-of-service guarantees are preserved all the way up the
   protocol stacks to the applications.  Protocols using available-bit-
   rate services may achieve better bandwidth utilization if they react
   to congestion messages from a fast packet switching network, and if
   they consider consequences of cell discard (e.g., if one cell of an
   IP datagram is discarded, it would be a waste to continue forwarding
   the rest of the cells in that datagram; also, selective retransmit
   should be revisited in this context).

インターネットプロトコルは基本的な速いパケット交換サービスで提供されるかもしれないサービスを利用するべきです。 一定のビット伝送速度、サービスが仕様を通常必要とする可変ビット伝送速度、および順応、アプリケーションかユーザからのトラフィック記述子とサービスの品質の仕様目的。 インターネットの同一時間のプロトコルは、速いパケット交換網で提供されるマルチメディアサービスを利用するためにメカニズムを前提とするべきであり、サービスの質保証がアプリケーションとしてプロトコル・スタックへのいっぱいに保持されるのを確実にしなければなりません。 速いパケット交換網、彼らがセル破棄の結果を考えるなら混雑メッセージに反応するなら、有効なビット-レートのサービスを利用するプロトコルは、より良い帯域幅利用を実現するかもしれません。また、(例えば、IPデータグラムの1つのセルが捨てられるなら、それはそのデータグラムのセルの残りを進め続けるためには浪費でしょう;、選択する、再訪しているコネがこの文脈であったなら再送する、)

   When the Internet protocol suite allows mixing of non-isochronous and
   isochronous traffic on one medium, it should provide mechanisms to

1つの媒体の上でインターネット・プロトコル群で非同一時間の、そして、同一時間のトラフィックを混入するのをメカニズムを前提とする場合

Britton & Tavs                                                  [Page 5]

RFC 1678     IPng Requirements of Large Corporate Networks   August 1994

大きい企業ネットワーク1994年8月のブリトンとTavs[5ページ]RFC1678IPng要件

   discourage inappropriate reservation of resources; e.g., a Telnet
   connection probably doesn't need to reserve 45Mbps.  Accounting,
   class-of-service, and well-known-port distinctions are possible ways
   to satisfy that requirement.

リソースの不適当な予約に水をさしてください。 例えば、Telnet接続はたぶん45Mbpsを予約する必要はありません。 会計、サービスのクラス、およびよく知られるポート区別はその要件を満たす可能な方法です。

Mobile Hosts

モバイルホスト

   Wireless technology opens up opportunities for new TCP/IP
   applications that are specific to mobile hosts.  In addition to
   coordinating with organizations developing wireless standards, the
   IETF also should encourage the specification of new TCP/IP
   applications enabled by wireless, such as connectionless messaging.

無線技術はモバイルホストにとって、特定の新しいTCP/IPアプリケーションの機会を開けます。 組織がワイヤレスの規格を開発していて調整することに加えて、IETFもワイヤレスによって可能にされた新しいTCP/IPアプリケーションの仕様を奨励するはずです、コネクションレスなメッセージングなどのように。

   IPng should deal well with the characteristics (delay, error rates4,
   etc.) peculiar to wireless.

IPngはワイヤレスに独特の特性(遅れ、誤りrates4など)によく、対処するはずです。

Topological flexibility

位相的な柔軟性

   Today a TCP/IP host moved to a different subnet needs a new IP
   address.  Such moves and changes can become a significant
   administrative cost.  Moreover, mobile hosts require flexible
   topology.  Note how the wireless world is trying to defeat the subnet
   model of addressing either by proxy or by IPaddress servers.  Perhaps
   IPng needs an addressing model more flexible than subnetting, both to
   reduce the administrative burden and to facilitate roaming users.

今日、異なったサブネットに動かされたTCP/IPホストは新しいIPアドレスを必要とします。 そのようなものは移行します、そして、変化は重要な管理費になることができます。 そのうえ、モバイルホストはフレキシブルなトポロジーを必要とします。 ワイヤレスの世界がどう代理人を通してかIPaddressでサーバを扱うサブネットモデルを破ろうとしているように注意してくださいか。 恐らく、IPngは、管理負担をともに減少させて、ユーザに移動するのを容易にするためにサブネッティングよりフレキシブルなアドレシングモデルを必要とします。

   The need to eliminate single points of failure drives the business
   requirement for multi-tail attachment of hosts to networks.
   Corporate users complain that TCP/IP can non-disruptively switch a
   connection from a broken route to a working one only if the new route
   leads to the same adapter on the end system.

単一のポイントの失敗を排除する必要性はホストのマルチテール付属のためのビジネス要件をネットワークに動かします。 企業ユーザーは、新しいルートがエンドシステムの上の同じアダプターに通じる場合にだけTCP/IPが非破壊的に壊れているルートから働くものまでの接続を切り換えることができると不平を言います。

Configuration, Administration and Operation

構成、政権、および操作

   Businesses would like dynamic but secure updating of Domain Name
   Servers, both to ease moves and changes and to facilitate cutover to
   backup hosts.  In this vein, secure and dynamic interaction between
   DNS and Dynamic Host Configuration Protocol (DHCP, RFC 1541) is
   required.  The IETF should encourage wide deployment of DHCP, and
   then solicit feedback on whether additional configuration
   requirements need to be satisfied.

ビジネスは、ともに移動と変化を緩和して、ホストのバックアップをとるためにカットオーバを容易にするためにDomain Name Serversのダイナミックな、しかし、安全なアップデートを必要とします。 この調子で、DNSとDynamic Host Configuration Protocol(DHCP、RFC1541)との安全でダイナミックな相互作用が必要です。 IETFはDHCPの広い展開を奨励して、次に、追加構成必要条件が、満たされる必要があるかどうかに関するフィードバックに請求するはずです。

Policy-Based Routing

方針ベースのルート設定

   Policy-based routing is a more a solution than a requirement.
   Businesses rarely require a general purpose policy architecture,
   although they do state requirements that policy-based routing could
   satisfy.  For example, corporations do not want to carry for free the

方針ベースのルーティングは要件より多くのa aソリューションです。 彼らは方針ベースのルーティングに満足させられることができたという要件を述べますが、ビジネスはめったに汎用の方針アーキテクチャを必要としません。 例えば、会社はただで運びたがっていません。

Britton & Tavs                                                  [Page 6]

RFC 1678     IPng Requirements of Large Corporate Networks   August 1994

大きい企業ネットワーク1994年8月のブリトンとTavs[6ページ]RFC1678IPng要件

   transit traffic of other enterprises, and they may not want their
   sensitive data to flow through links controlled by certain other
   enterprises.  Policy-based routing is one possible way to satisfy
   those requirements, but there seems to be a concern that general
   purpose policy-based routing may have high administrative cost and
   low routing performance.

他のある企業によって制御されて、流れる企業、および彼らが自分達の極秘データが欲しくないかもしれない他のトランジットトラフィックはリンクされます。 方針ベースのルーティングはそれらの要件を満たす1つの可能な方法ですが、汎用の方針ベースのルーティングには高い管理費と低ルーティング性能があるかもしれないという関心はあるように思えます。

Scaling

スケーリング

   If IPng satisfies the scaling requirement of the Internet, then it
   satisfies it for corporate networks a fortiori.

IPngがインターネットのスケーリング要件を満たすなら、それは企業ネットワークa fortioriのためにそれを満たします。

Conclusions

結論

   Enhancements to the Internet protocol suite, together with wider
   deployment of some of its existing architectures, could satisfy these
   requirement of commercial customers while retaining IPv4.  Expansion
   of the address space eventually will be necessary to allow continued
   Internet growth, but in RFC 1518 Tony Li and Yakov Rehkter have shown
   that from a technical perspective the addressing issue of IPng is not
   an immediate concern.

インターネット・プロトコル群への増進はIPv4を保有している間、商業顧客のこれらの要件をいくつかの既存のアーキテクチャの、より広い展開と共に満たすかもしれません。 アドレス空間の拡張が、結局、継続的なインターネットの成長を許容しますが、トニー・李とヤコフRehkterが示したRFC1518年に必要であるのに専門的見地からはIPngのアドレシング問題が目前の課題でないことが必要でしょう。

   Nevertheless, the TCP/IP community should establish a direction for
   enlargement of the address space, because unfounded publicity about
   the address space is scaring away potential TCP/IP users.  If the
   IETF does not provide direction on how its address space will grow,
   then people may use non-standard, and probably incompatible,
   approaches.

それにもかかわらず、TCP/IP共同体はアドレス空間の拡大のための方向を確立するべきです、アドレス空間に関する無根拠な宣伝が潜在的TCP/IPユーザを威して追い払っているので。 IETFがアドレス空間がどう成長するかに関する方向を提供しないなら、人々は標準的でなくて、たぶん両立しないアプローチを使用するかもしれません。

Security Considerations

セキュリティ問題

   The IETF should encourage wide deployment of GSS API, and then
   solicit feedback on whether additional security requirements need to
   be satisfied.  Businesses are so concerned about network cost control
   mechanisms that they want them secured against tampering.  IPng
   should not interfer with firewalls, which many corporations consider
   essential.  See other comments on Security throughout this memo.

IETFはGSS APIの広い展開を奨励して、次に、追加担保要件が、満たされる必要があるかどうかに関するフィードバックに請求するはずです。 ビジネスがネットワーク経費節減メカニズムに関して非常に心配しているので、彼らは改ざんに対してそれらを機密保護して欲しいです。 IPng(多くの会社が不可欠であると考える)はファイアウォールによるより多くのinterferにそうするべきではありません。 このメモ中でSecurityの他のコメントを見てください。

Britton & Tavs                                                  [Page 7]

RFC 1678     IPng Requirements of Large Corporate Networks   August 1994

大きい企業ネットワーク1994年8月のブリトンとTavs[7ページ]RFC1678IPng要件

Authors' Addresses

作者のアドレス

   Edward Britton
   IBM Corp.
   E69/503
   P.O.Box 12195
   Research Triangle Park, NC 27709

エドワードブリトンIBM社のE69/503私書箱12195リサーチトライアングル公園、NC 27709

   Phone: (919) 254-6037
   EMail: brittone@vnet.ibm.com

以下に電話をしてください。 (919) 254-6037 メールしてください: brittone@vnet.ibm.com

   John Tavs
   IBM Corp.
   E69/503
   P.O.Box 12195
   Research Triangle Park, NC 27709

ジョンTavs IBM社のE69/503私書箱12195リサーチトライアングル公園、NC 27709

   Phone: (919) 245-7610
   EMail: tavs@vnet.ibm.com

以下に電話をしてください。 (919) 245-7610 メールしてください: tavs@vnet.ibm.com

Britton & Tavs                                                  [Page 8]

ブリトンとTavs[8ページ]