RFC1380 日本語訳
1380 IESG Deliberations on Routing and Addressing. P. Gross, P.Almquist. November 1992. (Format: TXT=49415 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Gross
Request for Comments: 1380 IESG Chair
P. Almquist
IESG Internet AD
November 1992
コメントを求めるワーキンググループのP.の総計の要求をネットワークでつないでください: IESG議長P.Almquist IESGインターネット西暦1380年の1992年11月
IESG Deliberations on Routing and Addressing
ルート設定とアドレシングにおけるIESG熟考
Status Of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the Internet Engineering Task Force (IETF).
このメモはIPアーキテクチャでルーティングを囲んでいて、そのスケーリング問題を訴える問題をまとめます、そして、それはROADグループと関連活動の簡潔なバックグラウンドをインターネット・エンジニアリング・タスク・フォース(IETF)に提供します。
It also provides a preliminary report of the Internet Engineering Steering Group (IESG) deliberations on how these routing and addressing issues should be pursued in the Internet Architecture Board (IAB)/IETF.
また、それはこれらのルーティングと問題提示がインターネット・アーキテクチャ委員会(IAB)/IETFでどう追求されるべきであるかにおけるインターネットEngineering Steering Group(IESG)熟考に関する仮報告書を提供します。
Acknowledgements
承認
This note draws principally from two sources: the output from the ROAD group, as reported at the San Diego IETF meeting, and on numerous detailed discussions in the IESG following the San Diego IETF meeting. Zheng Wang, Bob Hinden, Kent England, and Bob Smart provided input for the "Criteria For Bigger Internet Addresses" section below. Greg Vaudreuil prepared the final version of the bibliography, based on previous bibliographies by Lyman Chapin and bibliographies distributed on the Big-Internet mailing list.
この注意は主に2つのソースを打ち解けさせます: ROADグループ、サンディエゴIETFミーティングで報告される、およびサンディエゴIETFミーティングに続くIESGの頻繁な詳細な論議の出力。 ツェンワング、ボブHinden、ケントイギリス、およびボブSmartは下の「より大きいインターネットアドレスの評価基準」セクションに入力を供給しました。 グレッグ・ボードルイは図書目録の最終版を準備しました、ライマン・チェーピンによる前の図書目録とBig-インターネットメーリングリストで配布された図書目録に基づいて。
Table of Contents
目次
1. INTRODUCTION.................................................. 2 2. ISSUES OF GROWTH AND EVOLUTION IN THE INTERNET............... 3 2.1 The Problems................................................ 3 2.2 Possible Solutions.......................................... 5 3. PREPARING FOR ACTION.......................................... 7 3.1 The IAB Architecture Retreats................................ 7 3.2 The Santa Fe IETF............................................ 7 3.3 The ROAD Group and beyond.................................... 8
1. 序論… 2 2. インターネットにおける成長と発展の問題… 3 2.1 問題… 3 2.2 可能なソリューション… 5 3. 動作の用意をします… 7 3.1 IABアーキテクチャは後退します… 7 3.2 サンタフェIETF… 7 3.3 ROAD Groupと以遠… 8
Gross & Almquist [Page 1] RFC 1380 ROAD November 1992
グロスとAlmquist[1ページ]RFC1380道路1992年11月
4. SETTING DIRECTIONS FOR THE IETF............................... 10
4.1 The Need For Interim Solutions............................... 10
4.2 The Proposed Phases.......................................... 10
4.3 A Solution For Routing Table Explosion -- CIDR............... 12
4.4 Regarding "IP Address Exhaustion"............................ 13
4.5 Milestones And Timetable For Making a Recommendation for
"Bigger Internet Addresses".................................. 14
5. SUMMARY....................................................... 15
Appendix A. FOR MORE INFORMATION................................. 16
Appendix B. INFORMATION AND SELECTION CRITERIA FOR "BIGGER
INTERNET ADDRESSES".................................. 16
Appendix C. BIBLIOGRAPHY......................................... 20
Security Considerations.......................................... 21
Authors' Addresses............................................... 22
4. IETFに方向を設定します… 10 4.1 当座のソリューションの必要性… 10 4.2 提案されたフェーズ… 10 ルート設定のための1ソリューションあたり4.3は爆発を見送ります--CIDR 12 4.4 「IPアドレス疲労困憊」に関して… 13 「より大きいインターネットアドレス」のために勧告するための4.5の重大事件とタイムテーブル… 14 5. 概要… 15 詳しい情報のための付録A.… 16 「より大きいインターネットアドレス」の付録B.情報と選択評価基準… 16 付録C.図書目録… 20 セキュリティ問題… 21人の作者のアドレス… 22
1. INTRODUCTION
1. 序論
It seems unlikely that the designers of IP ever imagined at the time what phenomenal success the Internet would achieve. Internet connections were initially intended primarily for mainframe computers at sites performing DARPA-sponsored research. Now, of course, the Internet has extended its reach to the desktop and is beginning to extend into the home. No longer the exclusive purview of pure R&D establishments, the Internet has become well entrenched in parts of the corporate world and is beginning to make inroads into secondary and even primary schools. While once it was an almost exclusively U.S. phenomenon, the Internet now extends to every continent and within a few years may well include network connections in every country.
IPのデザイナーが、今までにインターネットがどんな素晴らしい大成功を実現するかを当時、想像したのはありそうもなく見えます。 主としてDARPA-委託研究を実行するサイトのメインフレーム・コンピュータのために意図して、初めは、インターネット接続はそうでした。 もちろん、今、インターネットは範囲をデスクトップに広げて、ホームに広がり始めています。 もう純粋な研究開発施設の唯一の範囲、インターネットは実業界の地域でよく確立されるようになって、セカンダリの、そして、小学校にさえ侵入し始めています。 一度それは専ら米国の現象でしたが、インターネットは、現在、あらゆる大陸に達して、数年以内にたぶんあらゆる国にネットワーク接続を含んでいるでしょう。
Over the past couple of years, we have seen increasingly strong indications that all of this success will stress the limits of IP unless appropriate corrective actions are taken. The supply of unallocated Class B network numbers is rapidly dwindling, and the amount of routing information now carried in the Internet is increasingly taxing the abilities of both the routers and the people who have to manage them. Somewhat longer-term, it is possible that we will run out of host addresses or network numbers altogether.
過去2、3年間にわたって、私たちは適切な修正措置が取られないとこの成功のすべてがIPの限界を強調するというますます強い指摘を見ています。 unallocated Class Bネットワーク・ナンバーの供給は急速にやせ細っています、そして、今インターネットで運ばれたルーティング情報の量はますます彼らを管理しなければならない両方のルータと人々の能力に税をかけています。 いくらかより長い期間であり、私たちがホスト・アドレスか全体でネットワーク・ナンバーを使い果たすのは、可能です。
While these problems could be avoided by attempting to restrict the growth of the Internet, most people would prefer solutions that allow growth to continue. Fortunately, it appears that such solutions are possible, and that, in fact, our biggest problem is having too many possible solutions rather than too few.
インターネットの成長を制限するのを試みることによってこれらの問題を避けることができるだろうという間、ほとんどの人々が成長が続くソリューションを好むでしょう。 幸い、そのようなソリューションが可能であり、事実上、私たちの最も大きい問題にはわずか過ぎるよりむしろあまりに多くの可能なソリューションがあるように見えます。
This memo provides a preliminary report of IESG deliberations on how routing and addressing issues can be pursued in the IAB/IETF.
このメモはIAB/IETFでどうルーティングと問題提示を追求できるかにおけるIESG熟考に関する仮報告書を提供します。
Gross & Almquist [Page 2] RFC 1380 ROAD November 1992
グロスとAlmquist[2ページ]RFC1380道路1992年11月
In following sections, we will discuss in more detail the problems confronting us and possible approaches. We will give a brief overview of the ROAD group and related activities in the IETF. We will then discuss possible courses of action in the IETF. Ultimately, the IESG will issue a recommendation from the IESG/IETF to the IAB.
以下の章で、私たちはさらに詳細に私たちに立ち向かうことにおける問題と可能なアプローチについて議論するつもりです。 私たちはIETFでROADグループと関連活動の簡潔な概要を与えるつもりです。 そして、私たちはIETFで動作の可能な方針について議論するつもりです。 結局、IESGはIESG/IETFからIABまでの推薦を発行するでしょう。
2. ISSUES OF GROWTH AND EVOLUTION IN THE INTERNET
2. インターネットにおける成長と発展の問題
2.1 The Problems
2.1 問題
The Internet now faces three growth-related problems:
インターネットは現在、3つの成長関連の問題に直面しています:
- Class B network number exhaustion - Routing table explosion
- IP address space exhaustion
- クラスBネットワーク・ナンバー疲労困憊--経路指定テーブル爆発--IPアドレス空間疲労困憊
2.1.1 Class B Network Number Exhaustion
2.1.1 クラスBネットワーク・ナンバー疲労困憊
Over the last several years, the number of network numbers assigned and the number of network numbers configured into the Merit NSFnet routing database have roughly doubled every 12 months. This has led to estimates that, at the current allocation rate, and in the absence of corrective measures, it will take less than 2 years to allocate all of the currently unassigned Class B network numbers.
ここ数年間、数が割り当てたネットワークの数とMerit NSFnetルーティングデータベースに構成されたネットワーク・ナンバーの数は12カ月毎におよそ倍増しています。 これは現在の配分率において是正措置がないとき現在割り当てられなかったClass Bネットワーク・ナンバーのすべてを割り当てるには2年未満かかるという見積りに通じました。
After that, new sites which wished to connect more than the number of hosts possible in a single Class C (253 hosts) would need to be assigned multiple Class C networks. This will exacerbate the routing table explosion problems described next.
その後に、独身のClass C(253人のホスト)で可能なホストの数より接続したがっていた新しいサイトは、複数のClass Cネットワークに配属される必要があるでしょう。 これは次に説明された経路指定テーブル爆発問題を悪化させるでしょう。
2.1.2. Routing Table Explosion
2.1.2. 経路指定テーブル爆発
As the number of networks connected to the Internet has grown, the amount of routing information that has to be passed around to keep track of them all is likewise growing. This is leading to two types of problems.
インターネットに接続したネットワークの数が成長したのに従って、それらの皆、動向をおさえるために回されなければならないルーティング情報の量は同様に成長しています。 これは2つのタイプの問題を引き起こしています。
Hardware and Protocol Limits
ハードウェアとプロトコル限界
Routing protocols must pass around this information, and routers must store and use it. This taxes memory limits in the routers, and can also consume significant bandwidth when older routing protocols are used, (such as EGP and RIP, which were designed for a much smaller number of networks).
ルーティング・プロトコルがこの情報を回さなければならなくて、ルータは、それを保存して、使用しなければなりません。 これは、ルータにおけるメモリ限界に税をかけて、また、使用される、より古いルーティング・プロトコル、(はるかに少ない数のネットワークのために設計されたEGPとRIPとしてのそのようなもの)であるときに、重要な帯域幅を消費できます。
The limits on the memory in the routers seem to be the most pressing. It is already the case that the routers used in the MILNET are incapable of handling all of the current routes, and most other
ルータにおけるメモリにおける限界は最も緊急であるように思えます。 MILNETで使用されるルータが現在のルートのすべてを扱うことができないで、大部分が他は、既に事実です。
Gross & Almquist [Page 3] RFC 1380 ROAD November 1992
グロスとAlmquist[3ページ]RFC1380道路1992年11月
service providers have found the need to periodically upgrade their routers to accommodate ever larger quantities of routing information. An informal survey of router vendors by the ROAD group estimated that most of the currently deployed generation of high-end routers will support O(16000) routes. This will be probably be adequate for the next 12 to 18 months at the current rate of growth. Most vendors have begun, or will soon begin, to ship routers capable of handling O(64000) routes, which should be adequate for an additional two years if the above Class B Network Number Exhaustion problem is solved.
サービスプロバイダーは多く以上の量のルーティング情報に対応するためにそれらのルータを定期的にアップグレードさせる必要性を見つけました。 ROADグループによるルータベンダーの非公式の調査は、ハイエンドルータの現在配布している世代の大部分がO(16000)にルートを支えると見積もっていました。 これは次の12〜18カ月、たぶん現在の成長率で適切であるためにことになるでしょう。 ほとんどのベンダーが始まったか、またはすぐ、上のClass B Network Number Exhaustion問題が解決されているなら追加2年間適切であるべき取り扱いO(64000)ルートができるルータを出荷するために始まるでしょう。
Human Limits
人間として耐えられる限界
The number of routes does not merely tax the network's physical plant. Network operators have found that the inter-domain routing protocol mechanisms often need to be augmented by a considerable amount of configuration to make the paths followed by packets be consistent with the policies and desires of the network operators. As the number of networks increases, the configuration (and the traffic monitoring to determine whether the configuration has been done correctly) becomes increasingly difficult and time-consuming.
ルートの数は単にネットワークの施設に税をかけません。 ネットワーク・オペレータは、そのかなりの量の構成によって増大している、パケットがあとに続いた経路を作るべきであるしばしばプロトコルメカニズムを発送する相互ドメインの必要性がネットワーク・オペレータの方針と願望と一致しているのがわかりました。 ネットワークの数が増加するのに従って、構成(そして、構成が正しく完了していたか否かに関係なく、決定するトラフィックモニター)はますます難しく手間がかかるようになります。
Although it is not possible to determine a number of networks (and therefore a time frame) where human limits will be exceeded, network operators view this as a significant short-term problem.
人間として耐えられる限界が超えられている多くのネットワーク(そして、したがって、時間枠)を決定するのが可能ではありませんが、ネットワーク・オペレータは重要な短期的な問題であるとこれをみなします。
2.1.3. IP Address Exhaustion
2.1.3. IPアドレス疲労困憊
If the current exponential growth rate continues unabated, the number of computers connected to the Internet will eventually exceed the number of possible IP addresses. Because IP addresses are divided into "network" and "host" portions, we may not ever fully run out of IP addresses because we will run out of IP network numbers first.
現在の指数関数的な成長率が変わらない状態で続くと、インターネットに接続されたコンピュータの数は結局、可能なIPアドレスの数を超えるでしょう。 IPアドレスが「ネットワーク」と「ホスト」部分に分割されて、私たちは、最初にIPネットワーク・ナンバーを使い果たすつもりであるので、完全にIPアドレスを使い果たすかもしれないというわけではありません。
There is considerable uncertainty regarding the timeframe when we might exceed the limits of the IP address space. However, the issue is serious enough that it deserves our earliest attention. It is very important that we develop solutions to this potential problem well before we are in danger of actually running out of addresses.
私たちがIPアドレス空間の限界を超えるかもしれないとき、時間枠に関して相当の不確実性があります。 しかしながら、問題は私たちの最も早い留意に値するほど重大です。 私たちに実際にアドレスを使い果たすという危険がある前に私たちがこの潜在的な問題に解決策をよく見いだすのは、非常に重要です。
2.1.4. Other Internetwork Layer Issues
2.1.4. 他のインターネットワーク層の問題
Although the catalog of problems above is pretty complete as far as the scaling problems of the Internet are concerned, there are other Internet layer issues that will need to be addressed over the coming years. These are issues regarding advanced functionality and service guarantees in the Internet layer.
インターネットのスケーリング問題に関する限り、問題の上記のカタログはかなり完全ですが、来たる年の間、扱われる必要がある他のインターネット層の問題があります。 これらは、高度な機能性に関する問題とインターネット層でサービス保証です。
In any attempt to resolve the Internet scaling problems, it is
インターネットスケーリング問題を解決するどんな試みでも、それはそうです。
Gross & Almquist [Page 4] RFC 1380 ROAD November 1992
グロスとAlmquist[4ページ]RFC1380道路1992年11月
important to consider how these other issues might affect the future evolution of Internet layer protocols. These issues include:
これらの他の問題がどのようにインターネット層プロトコルの今後の発展に影響するかもしれないかを考えるために、重要です。 これらの問題は:
1) Policy-based routing
2) Flow control
3) Weak Quality-of-Service (QOS)
4) Service guarantees (strong QOS)
5) Charging
1) 方針ベースのルーティング2) フロー制御3) 弱いサービスの質(QOS) 4) サービス保証(強いQOS) 5) 充電
2.2 Possible Solutions
2.2 可能なソリューション
2.2.1. Class B Network Number Exhaustion
2.2.1. クラスBネットワーク・ナンバー疲労困憊
A number of approaches have been suggested for how we might slow the exhaustion of the Class B IP addresses. These include:
私たちがどうClass B IPアドレスの疲労困憊を遅くすることができるように、多くのアプローチが示されたか。 これらは:
1) Reclaiming those Class B network numbers which have been
assigned but are either unused or used by networks which are not
connected to the Internet.
1) それらの割り当てられましたが、未使用であることのClass Bネットワーク・ナンバーを取り戻すか、またはインターネットに接続されないネットワークによって使用されます。
2) Modifying address assignment policies to slow the assignment
of Class B network numbers by assigning multiple Class C network
numbers to organizations which are only a little bit to big to be
accommodated by a Class C network number.
2) Class Cネットワーク・ナンバーによって設備されるためにほんの少し大きくだけある組織に複数のClass Cネットワーク・ナンバーを配属することによってClass Bネットワーク・ナンバーの課題を遅くするようにアドレス課題方針を変更します。
Note: It is already the case that a Class B number is assigned
only if the applicant would need more than "several" Class C
networks. The value of "several" has increased over time from
1 to (currently) 32.
以下に注意してください。 応募者が「数個」のClass Cネットワーク以上を必要とする場合にだけClass B番号が割り当てられるのは、既に事実です。 「数個」の値は時間がたつにつれて、(現在)の1対32から増えました。
3) Use the Class C address space to form aggregations of
different size than the normal normal Class C addresses. Such
schemes include Classless Inter-Domain Routing (CIDR) [Fuller92]
and the C# scheme [Solen92].
3) 正常な正常なClass CアドレスよりClass Cアドレス空間を使用して、異なったサイズの集合を形成してください。 そのような体系はClassless Inter-ドメインルート設定(CIDR)を含んでいます。 [Fuller92]とC#体系[Solen92]。
2.2.2. Routing Table Explosion
2.2.2. 経路指定テーブル爆発
As was described earlier, there are actually two parts to this problem. They each have slightly different possible approaches:
より早く説明されたように、この問題への2つの部品が実際にあります。 彼らには、それぞれわずかに異なった可能なアプローチがあります:
Hardware and Protocol Limits
ハードウェアとプロトコル限界
1) More thrust. We could simply recognize the fact that routers
which need full Internet routing information will require large
amounts of memory and processing capacity. This is at best a very
short-term approach, and we will always need to face this problem
in the long-term.
1) 以上は突き出します。 私たちは単に、完全なインターネット・ルーティング情報を必要とするルータが多量のメモリと処理容量を必要とするという事実を認めることができました。 これはせいぜい非常に短期的なアプローチです、そして、私たちはいつも長期にこの問題に直面する必要があるつもりです。
Gross & Almquist [Page 5] RFC 1380 ROAD November 1992
グロスとAlmquist[5ページ]RFC1380道路1992年11月
2) Route servers (a variant of the "More Thrust" solution).
Instead of requiring every router to store complete routing
information, mechanisms could be developed to allow the tasks of
computing and storing routes to be offloaded to a server. Routers
would request routes from the server as needed (presumably caching
to improve performance).
2) サーバ(「より多くの突き」ソリューションの異形)を発送してください。 完全なルーティング情報を保存するためにあらゆるルータを必要とすることの代わりに、ルートを計算して、保存するタスクがサーバへ積み下ろされるのを許容するためにメカニズムを開発できました。ルータは、必要に応じて(性能を向上させるおそらくキャッシュ)サーバからルートを要求するでしょう。
3) Topology engineering. Many network providers already try to
design their networks in such a way that only a few of the routers
need complete routing information (the others rely on default
routes to reach destinations that they don't have explicit routes
to). While this is inconvenient for network operators, it is a
trend which is likely to continue.
3) トポロジー工学。 多くのネットワーク内の提供者が既にほんのルータのいくつかが完全なルーティング情報を必要とするような(他のものはそれらが明白なルートを持っていない目的地に達するようにデフォルトルートを当てにします)方法でそれらのネットワークを設計しようとします。 ネットワーク・オペレータにとって、これは不便ですが、どれが継続的でありそうであるかは、傾向です。
It is also the case that network providers could further reduce
the number of routers which need full routing information by
accepting some amount of suboptimal routing or reducing alternate
paths used for backup.
また、ネットワーク内の提供者がいくらかの量の準最適のルーティングを受け入れるか、またはバックアップに使用される代替パスを減少させることによって完全なルーティング情報を必要とするルータの数をさらに減少させるかもしれないのは、事実です。
4) Charging-based solutions. By charging for network number
advertisements, it might be possible to discourage sites from
connecting more networks to the Internet than they get significant
value from having connected.
4) 充電ベースのソリューション。 ネットワーク・ナンバー広告に課金することによって、サイトが接続するのを思いとどまるために、それらより多くのネットワークがインターネットに接続したのから重要な値を得るのは、可能であるかもしれません。
5) Aggregation of routing information. It is fairly clear that in
the long-term it will be necessary for addresses to be more
hierarchical. This will allow routes to many networks to be
collapsed into a single summary route. Therefore, an important
question is whether aggregation can also be part of the short-term
solution. Of the proposals to date, only CIDR could provide
aggregation in the short-term. All longer-term proposals should
aggregation.
5) ルーティング情報の集合。 長期では、アドレスが、より階層的であることが必要であることは、かなり明確です。 これで、多くのネットワークへのルートはただ一つの概要ルートに潰れるでしょう。 したがって、重要な質問はまた、集合が短期的なソリューションの一部であるかもしれないかどうかということです。 これまでの提案では、CIDRだけが短期間集合を提供できました。 すべての、より長い期間提案は集合がそうするべきです。
Human Limits
人間として耐えられる限界
1) Additional human resources. Network providers could devote
additional manpower to routing management, or accept the
consequences of a reduced level of routing management. This is
obviously unattractive as anything other than a very short-term
solution.
1) 追加人的資源。 ネットワーク内の提供者は、ルーティング管理に追加労働力をささげるか、または減少しているレベルのルーティング管理の結果を受け入れるかもしれません。 これは非常に短期的なソリューション以外の何としてでも明らかにつまらないです。
2) Better tools. Network operators and router vendors could work
to develop more powerful paradigms and mechanisms for routing
management.
2) より良いツール。 ネットワーク・オペレータとルータベンダーは、ルーティング管理のために、より強力なパラダイムとメカニズムを開発するために働くことができました。
The IETF has already undertaken some work in the areas of route
filtering and route leaking.
IETFは既にルートフィルタリングとルート漏出の領域でのいくらかの仕事を引き受けました。
Gross & Almquist [Page 6] RFC 1380 ROAD November 1992
グロスとAlmquist[6ページ]RFC1380道路1992年11月
2.2.3. IP Address Exhaustion
2.2.3. IPアドレス疲労困憊
The following general approaches have been suggested for dealing with the possible exhaustion of the IP address space:
以下の一般的方法はIPアドレス空間の可能な疲労困憊に対処するために示されました:
1) Protocol modifications to provide a larger address space. By
enhancing IP or by transitioning to another protocol with a larger
address space, we could substantially increase the number of
available network numbers and addresses.
1) 変更について議定書の中で述べて、より大きいアドレス空間を提供してください。 IPを高めるか、または、より大きいアドレス空間に従って別のプロトコルに移行することによって、私たちは有効なネットワーク・ナンバーとアドレスの数をかなり増強できるでしょう。
2) Addresses which are not globally unique. Several proposed
schemes have emerged whereby a host's domain name is globally
unique, but its IP address would be unique only within it's local
routing domain. These schemes usually involve address translating
2) グローバルにユニークでないアドレス。 ホストのドメイン名がグローバルにユニークであるいくつかの提案された体系が現れましたが、IPアドレスはそれだけの中でユニークであるのが、地方の経路ドメインであるということでしょう。 通常、これらの体系はアドレス翻訳にかかわります。
3) Partitioned Internet. The Internet could be partitioned into
areas, such that a host's IP address would be unique only within
its own area. Such schemes generally postulate application
gateways to interconnect the areas. This is not unlike the
approach often used to connect differing protocol families.
3) インターネットを仕切りました。 インターネットを領域に仕切ることができました、ホストのIPアドレスがそれ自身の領域だけの中でユニークであるように。 一般に、そのような体系は、領域とインタコネクトするためにアプリケーションゲートウェイを仮定します。 これは異なったプロトコルファミリーに接するのにしばしば使用されるアプローチと似ています。
4) Reclaiming network numbers. Network numbers which are not
used, or are used by networks which are not connected to the
Internet, could conceivably be reclaimed for general Internet use.
This isn't a long-term solution, but could possibly help in the
interim if for some reason address exhaustion starts to occur
unexpectedly soon.
4) ネットワーク・ナンバーを取り戻します。 一般的なインターネットの利用のために多分使用されていないか、またはインターネットに接続されないネットワークによって使用されるネットワーク・ナンバーは取り戻すことができました。 これは、長期的な解決法ではありませんが、ある理由でアドレス疲労困憊がすぐ不意に起こり始めるなら、その間助けるかもしれません。
3. PREPARING FOR ACTION
3. 動作の用意をします。
3.1 The IAB Architecture Retreats
3.1 IABアーキテクチャは後退します。
In July 1991, the IAB held a special workshop to consider critical issues in the IP architecture (Clark91). Of particular concern were the problems related to Internet growth and scaling. The IAB felt the issues were of sufficient concern to begin organizing a special group to explore the issues and to explore possible solutions. Peter Ford (LANL) was asked to organize this effort. The IAB reconvened the architecture workshop in January 1992 to further examine these critical issues, and to meet jointly with the then-formed ROAD group (see below).
1991年7月に、IABは、IPアーキテクチャ(Clark91)の重要な問題を考えるために特別なワークショップを開きました。 特定では、関心は、インターネットの成長に関連する問題であり、比例しています。 IABは、問題が特別なグループが問題を探って、可能なソリューションについて調査するのを組織化し始めるためには十分な関心のものであると感じました。 ピーター・フォード(LANL)がこの取り組みを組織化するように頼まれました。 IABは、1992年1月にさらにこれらの重要な問題を調べて、次に、形成されたROADグループと一緒に会うためにアーキテクチャワークショップを再召集しました(以下を見てください)。
3.2 The Santa Fe IETF
3.2 サンタフェIETF
At the November 1991 Santa Fe IETF meeting, the BGP Working Groups independently began a concerted exploration of the issues of routing table scaling. The principal approach was to perform route aggregation by using address masks in BGP to do "supernetting"
1991年11月のサンタフェのIETFミーティングでは、BGP Working Groupsは独自に経路指定テーブルスケーリングの問題の協定している探検を始めました。 主要なアプローチは「スーパーネッティング」をするのにBGPでアドレスマスクを使用することによってルート集合を実行することでした。
Gross & Almquist [Page 7] RFC 1380 ROAD November 1992
グロスとAlmquist[7ページ]RFC1380道路1992年11月
(rather than "subnetting"). This approach would eventually evolve into CIDR. The BGP WG decided to form a separate subgroup, to be led by Phill Gross (ANS) to pursue this solution.
(「サブネッティング」よりむしろ。) このアプローチは結局、CIDRに発展するでしょう。BGP WGは、別々のサブグループを形成して、このソリューションを追求するようにフィルGross(ANS)によって導かれると決めました。
3.3 The ROAD Group and Beyond
3.3 道路グループと以遠
At the Santa Fe IETF, the initially separate IAB and BGP WG activities were combined into a special effort, named the "ROuting and ADdressing (ROAD) Group", to be co-chaired by Ford and Gross.
サンタフェIETFでは、初めは別々のIABとBGP WG活動は共同議長を務めるためには「(道路)グループを発送して、演説します」フォードとGrossという特別な取り組みに結合されました。
The group was asked to explore possible near-term approaches for the scaling problems described in the last section, namely:
グループが最後のセクションで説明されたスケーリング問題のための可能な短期間アプローチについて調査するように頼まれた、すなわち:
- Class B address exhaustion
- Routing table explosion
- IP address space exhaustion
- クラスBアドレス疲労困憊--経路指定テーブル爆発--IPアドレス空間疲労困憊
The ROAD group was asked to report back to the IETF at the San Diego IETF (March 1992). Suggested guidelines included minimizing changes to hosts, must be incrementally deployable, and must provide support for a billion networks.
ROADグループがサンディエゴIETF(1992年3月)のIETFに報告を持ちかえるように頼まれました。 提案されたガイドラインは、増加して配布可能することでなければならなく、ホストへの変化を最小にするのを含んで、10億のネットワークのサポートを前提としなければなりません。
The ROAD group was not a traditional open IETF working group. It was always presumed that this was a one-time special group that would lead to the formation of other IETF WGs after its report in San Diego.
ROADグループは伝統的な開いているIETFワーキンググループではありませんでした。 いつもこれがレポートの後にサンディエゴで他のIETF WGsの構成につながる1回の特別なグループであると推定されました。
The ROAD group held several face-face meetings between the November 1991 (Santa Fe) and March 1992 (San Diego) IETF meetings. This included several times at the Santa Fe IETF meeting, December 1991 in Reston VA, January 1992 in Boston (in conjunction with the IAB architecture workshop), and January 1992 in Arizona). There was also much discussion by electronic mail.
ROADグループは1991年11月の(サンタフェ)と1992年3月(サンディエゴ)IETFミーティングとのいくつかの表面表面会合を開きました。 サンタフェのIETFミーティング、レストンヴァージニアの1991年12月、ボストン(IABアーキテクチャワークショップに関連した)の1992年1月、およびアリゾナの1992年1月に何度かこれを含んでいます) また、電子メールによる多くの議論がありました。
The group produced numerous documents, which have variously been made available as Internet-Drafts or RFCs (see Bibliography in Appendix D).
グループは多数のドキュメントを製作しました(Appendix DのBibliographyを見てください)。(ドキュメントはさまざまにインターネット草稿かRFCsとして利用可能にされました)。
As follow-up, the ROAD co-chairs reported to the IETF plenary in March 1992 in San Diego. Plus, several specific ROAD-related activities took place during the IETF meeting that week.
フォローアップとして、ROAD共同議長は1992年3月にサンディエゴで絶対的なIETFに報告しました。 そのうえ、いくつかの特定のROAD関連の活動がその週にIETFミーティングの間、行われました。
The Ford/Gross presentation served as a preliminary report from the ROAD group. The basic thrust was:
フォード/総計のプレゼンテーションはROADグループからの仮報告書として機能しました。 基本的な突きは以下の通りでした。
1. The Internet community needs a better way to deal with current
addresses (e.g., hierarchical address assignments for routing
aggregation to help slow Class B exhaustion and routing table
1. インターネットコミュニティが現在のアドレスに対処するより良い方法を必要とする、(例えばルーティング集合が助ける階層的なアドレス課題はClass B疲労困憊と経路指定テーブルを遅くします。
Gross & Almquist [Page 8] RFC 1380 ROAD November 1992
グロスとAlmquist[8ページ]RFC1380道路1992年11月
explosion). Classless Inter-Domain Routing (CIDR; also called
"supernetting") was recommended. CIDR calls for:
爆発) 階級のない相互ドメインルート設定、(CIDR。 また、呼ばれた「スーパーネッティング」) 推薦されました。 CIDRは以下のために呼びます。
- The development of a plan for hierarchical IP address
assignment for aggregation in routing,
- ルーティングによる集合のための階層的なIPアドレス課題のためのプランの開発
- Enhanced "classless" Inter-domain protocols (i.e., carry
address masks along with IP addresses),
- 「階級のない」Inter-ドメインプロトコル(すなわち、IPアドレスに伴うアドレスマスクを運ぶ)を高めました。
- Inter-Domain routing "Usage documents" for using addressing
and routing plan with the enhanced inter-domain protocols,
and for interacting with IGPs.
- アドレシングとルーティングを使用するための相互Domainルーティング「用法ドキュメント」は、高められた相互ドメインプロトコルと、IGPsと対話するために計画されています。
2. The Internet community needs bigger addresses for the Internet
to stem IP address exhaustion. The ROAD group explored several
approaches in some depth. Some of these approaches were discussed
at the San Diego IETF. However, a final recommendation of a
single approach did not emerge.
2. インターネットがIPアドレス疲労困憊を食い止めるように、インターネットコミュニティは、より大きいアドレスを必要とします。 ROADグループは何らかの深さでのいくつかのアプローチについて調査しました。 サンディエゴIETFでこれらのアプローチのいくつかについて議論しました。 しかしながら、ただ一つのアプローチの最終勧告は現れませんでした。
3. The Internet community needs to focus more effort on future
directions for Internet routing and advanced Internet layer
features.
3. インターネットコミュニティは、インターネット・ルーティングと高度なインターネット層の機能のために将来の方向により多くの取り組みの焦点を合わせる必要があります。
Other ROAD-related activities at the San Diego IETF meeting included:
サンディエゴIETFミーティングにおける他のROAD関連の活動は:だった
- Monday, 8:00 - 9:00 am, Report from the ROAD group on
"Internet Routing and Addressing Considerations",
- 月曜日に、8:00〜午前9時0分まで、ROADからのReportは「インターネットルート設定と問題を扱う」とき分類します。
- Monday, 9:30-12:00pm, Geographical Addressing and Routing
(during NOOP WG session),
- 月曜日、午後9時30分から12時0分、Geographical Addressing、およびルート設定(NOOP WGセッションの間の)
- Monday, 1:30-3:30pm, Preliminary discussion of a CIDR routing
and addressing plan (during ORAD session),
- 月曜日、午後1時30分から3時30分、CIDRルーティングとアドレシングプラン(ORADセッションの間の)のPreliminary議論
- Tuesday, 1:30-6:00pm, Internet Routing and Addressing BOF (to
discuss ROAD results and to explore approaches for bigger Internet
address space),
- 火曜日、午後1時30分から6時0分、インターネットルート設定、およびAddressing BOF(ROAD結果について議論して、より大きいインターネット・アドレススペースのためのアプローチについて調査する)
- Wednesday, 1:30-3:30pm, CIDR Supernetting BOF (joint with BGP
WG),
- 水曜日、午後1時30分から3時30分、CIDRスーパーネッティング転炉(BGP WGがあるジョイント)
- Thursday, 4:00-6:00pm, Summary of ROAD activities in San Diego
followed by open plenary discussion.
- 木曜日に、午後4時0分から6時0分、サンディエゴでのROAD活動のSummaryは開いている本議論で続きました。
The slides for the Monday presentation (Ford92), slides for the Thursday summary (and notes in the Chair's message) (Gross92), and notes for the other sessions are contained in the Proceedings of the Twenty-Third IETF (San Diego).
月曜日のプレゼンテーションのためのスライド(Ford92)、木曜日の概要(そして、議長のメッセージでの注意)のためのスライド(Gross92)、および他のセッションのためのメモはTwenty-第3IETF(サンディエゴ)のProceedingsに含まれています。
Gross & Almquist [Page 9] RFC 1380 ROAD November 1992
グロスとAlmquist[9ページ]RFC1380道路1992年11月
4. SETTING DIRECTIONS FOR THE IETF
4. IETFに方向を設定します。
4.1 The Need For Interim Solutions
4.1 当座のソリューションの必要性
Solutions to the problems of advanced Internet layer functionality are far from being well understood. While we should certainly encourage research in these areas, it is premature to start an engineering effort for an Internet layer which would solve not only the scaling problems but also those other issues.
高度なインターネット層の機能性の問題の解決はよく理解されるのから遠いです。 私たちは確かにこれらの領域で研究を奨励するべきですが、スケーリング問題だけではなく、それらの他の問題も解決するインターネット層のための技術的努力を始めるのは時期尚早です。
Plus, most approaches to the problem of IP address space exhaustion involve changes to the Internet layer. Such approaches mean changes changes to host software that will require us to face the very difficult transition of a large installed base.
そのうえ、IPアドレス空間疲労困憊の問題へのほとんどのアプローチがインターネット層への変化にかかわります。 アプローチが意味するそのようなものは、私たちが大きいインストールされたベースの非常に難しい変遷に直面しているのを必要とするソフトウェアをホスティングするために変化を変えます。
It is therefore not likely that we can (a) develop a single solution for the near-term scaling problems that will (b) also solve the longer-term problems of advanced Internet-layer functionality, that we can (c) choose, implement and deploy before the nearer-term problems of Class B exhaustion or routing table explosion confront us.
したがって、私たちは立ち向かうことができそうにはありません。(a) (b) また、そうするスケーリング問題が高度なインターネット層の機能性の、より長い期間問題を解決して、私たちがそうすることができる短期間(c)が選ばれるので、ただ一つの解決策を見いだすか、より多くの用語頃のClass B疲労困憊の問題の前に実装して、展開するか、またはテーブル爆発を発送して、私たちに立ち向かってください。
This line of reasoning leads to the inevitable conclusion that we will need to make major enhancements to IP in (at least) two stages.
推理のこの系列は私たちが、(少なくとも)の2におけるIPへの主要な増進をステージにする必要があるつもりであるという必然の結論につながります。
Therefore, we will consider interim measures to deal with Class B address exhaustion and routing table explosion (together), and to deal with IP address exhaustion (separately).
したがって、私たちは、経過措置がClass Bアドレス疲労困憊と経路指定テーブル爆発に(一緒に)対処して、(別々に)IPアドレス疲労困憊に対処すると考えるつもりです。
We will also suggest that the possible relation between these nearer- term measures and work toward advanced Internet layer functionality should be made an important consideration.
また、私たちは、これらのより近い用語測定の可能な関係と高度なインターネット層の機能性に向かった仕事をするべきであると示唆するつもりです。重要な考慮すべき事柄。
4.2 The Proposed Phases
4.2 提案されたフェーズ
The IESG recommends that we divide the overall course of action into several phases. For lack of a better vocabulary, we will term these "immediate", "short-term", mid-term", and "long-term" phases. But, as the ROAD group pointed out, we should start all the phases immediately. We cannot afford to act on these phases consecutively!
IESGは、私たちが総合的な行動をいくつかのフェーズに分割することを勧めます。 「より良いボキャブラリーの不足によって、私たちは用語に「即座で」、「短期的」と、中期でこれらを望んでいる」、および「長期」のフェーズ。 しかし、ROADグループが指摘したように、私たちはすぐに、すべてのフェーズを始めるべきです。 私たちには連続してこれらのフェーズに影響する余裕がありません!
In brief, the phases are:
要するに、フェーズは以下の通りです。
- "Immediate". These are configuration and engineering actions that
can take place immediately without protocol design, development, or
deployment. There are a number of actions that can begin
immediately. Although none of these will solve any of the problems,
they can help slow the onset of the problems.
- 「即座です」。 これらは、すぐにプロトコルデザインも、開発も、または展開なしで行われることができる構成と工学動作です。 すぐに始まることができる多くの動作があります。 これらのいずれも問題のいずれも解決しないでしょうが、それらは、問題の開始を遅くするのを助けることができます。
Gross & Almquist [Page 10] RFC 1380 ROAD November 1992
グロスとAlmquist[10ページ]RFC1380道路1992年11月
The IESG specifically endorses:
IESGは明確に以下を是認します。
1) the need for more conservative address assignment
policies,
2) alignment of new address assignment policies with any new
aggregation schemes,
3) efforts to reclaim unused Class B addresses,
4) installation of more powerful routers by network operators
at key points in the Internet, and
5) careful attention to topology engineering.
1) より保守的なアドレス課題方針の必要性、どんな新しい集合計画、3がある新しいアドレス課題方針の2)整列) 未使用のClass Bアドレス、4を取り戻すための努力) インターネットの要所におけるネットワーク・オペレータによる、より強力なルータのインストール、およびトポロジー工学に関する5の)慎重な注意。
- "Short-term". Actions in this phase are aimed at dealing with
Class B exhaustion and routing table explosion. These problems are
deemed to be quite pressing and to need solutions well before the IP
address exhaustion problem needs to be or could be solved. In this
timeframe, changes to hosts can *not* be considered.
- 「短期的です」。 このフェーズにおける動作はClass B疲労困憊と経路指定テーブル爆発に対処するのを目的とされます。 これらの問題をかなり押していて、疲労困憊問題が必要があるIPアドレスであるよく前に解決策を必要とすると考えたか、または解決できました。 この時間枠では、**考えられないで、ホストへの変化はそうすることができます。
- "Mid-term". In the mid-term, the issue of IP address exhaustion
must be solved. This is the most fundamental problem facing the IP
architecture. Depending on the expected timeframe, changes to host
software could be considered. Note: whatever approach is taken, it
must also deal with the routing table explosion. If it does not,
then we will simply be forced to deal with that problem again, but in
a larger address space.
- 「中期です」。 中期では、IPアドレス疲労困憊の問題を解決しなければなりません。 これはIP構造に直面するのにおいて最も基本的な問題です。 予想された時間枠によって、ホストソフトウェアへの変化を考えることができました。 以下に注意してください。 また、どんなアプローチも取っても、それは経路指定テーブル爆発に対処しなければなりません。 それがそうしないと、その問題が再び単に対処させられますが、私たちは、より大きいアドレス空間でそうするでしょう。
- "Long-term". Taking a broader view, the IESG feels that advanced
Internet layer functionality, like QOS support and resource
reservation, will be crucial to the long-term success of the Internet
architecture.
- 「長期的です」。 大局的に見て、IESGは、高度なインターネット層の機能性がQOSサポートと資源予約のようにインターネット構造の長期の成功に重要になるのを感じます。
Therefore, planning for advanced Internet layer functionality should play a key role in our choice of mid-term solutions.
したがって、高度なインターネット層の機能性の計画を立てるのは私たちの中期の解決策の選択で重要な役割を果たすべきです。
In particular, we need to keep several things in mind:
特に、私たちは、いくつかのことを覚えておく必要があります:
1) The long-term solution will require replacement and/or
extension of the Internet layer. This will be a significant
trauma for vendors, operators, and for users. Therefore, it is
particularly important that we either minimize the trauma involved
in deploying the sort-and mid-term solutions, or we need to assure
that the short- and mid-term solutions will provide a smooth
transition path for the long-term solutions.
1) 長期的な解決法はインターネット層の交換、そして/または、拡大を必要とするでしょう。 これは業者、オペレータとユーザにとって、重要なトラウマになるでしょう。 そして、したがって、私たちが展開にかかわるトラウマを最小にするのが、特に重要である、種類、-、中期の解決策、私たちは、短くて中期の解決策がスムーズな移行経路を長期的な解決法に提供することを保証する必要があります。
2) The long-term solution will likely require globally unique
endpoint identifiers with an hierarchical structure to aid
routing. Any effort to define hierarchy and assignment mechanisms
for short- or mid-term solutions would, if done well, probably
have long-term usefulness, even if the long-term solution uses
2) 長期的な解決法は、ルーティングを支援するためにおそらく階層構造があるグローバルにユニークな終点識別子を必要とするでしょう。 上手にするなら短いか中期の解決策のために階層構造と割当機構を定義するためのどんな努力にも長期の有用性がたぶんあるだろう、長期的な解決法は使用します。
Gross & Almquist [Page 11] RFC 1380 ROAD November 1992
グロスとAlmquist[11ページ]RFC1380道路1992年11月
radically different message formats.
根本的に異なったメッセージ・フォーマット。
3) To some extent, development and deployment of the interim
measures will divert resources away from other important projects,
including the development of the long-term solution. This
diversion should be carefully considered when choosing which
interim measures to pursue.
3) ある程度、一時的な方策の開発と展開は他の重要な計画から遠くにリソースを紛らすでしょう、長期的な解決法の開発を含んでいて。 どの一時的な方策を追求したらよいかを選ぶとき、この転換は慎重に考えられるべきです。
4.3 A Solution For Routing Table Explosion -- CIDR
経路指定テーブル爆発のための1ソリューションあたり4.3--CIDR
The IESG accepted ROAD's endorsement of CIDR [Fuller92]. CIDR solves the routing table explosion problem (for the current IP addressing scheme), makes the Class B exhaustion problem less important, and buys time for the crucial address exhaustion problem.
IESGはROADのCIDR[Fuller92]の裏書きを受け入れました。 CIDRは経路指定テーブル爆発問題(現在のIPアドレシング計画のための)を解決して、Class B疲労困憊問題をより重要でなくして、重要なアドレス疲労困憊問題によって時間を稼ぎます。
The IESG felt that other alternatives (e.g., C#, see Solen92) did not provide both routing table aggregation and Class B conservation at comparable effort.
IESGは、他の代替手段(例えば、C#、Solen92を見る)が匹敵する努力で経路指定テーブル集合とClass B保護の両方を提供しなかったと感じました。
CIDR will require policy changes, protocol specification changes, implementation, and deployment of new router software, but it does not call for changes to host software.
CIDRは新しいルータソフトウェアの政策変更、プロトコル仕様書変更、実現、および展開を必要とするでしょうが、それは、ソフトウェアをホスティングするために変化を求めません。
The IESG recommends the following course of action to pursue CIDR in the IETF:
IESGは、以下の行動がIETFでCIDRを追求することを勧めます:
a. Adopt the CIDR model described in Fuller92.
a。 Fuller92で説明されたCIDRモデルを採用してください。
b. Develop a plan for "IP Address Assignment Guidelines".
b。 「IPアドレス課題ガイドライン」には、計画を作り上げてください。
The IESG considered the creation of an addressing plan to be an
operational issue. Therefore, the IESG asked Bernhard Stockman
(IESG Operational Requirements Area Co-Director) to lead an effort
to develop such a plan. Bernhard Stockman is in a position to
bring important international input (Stockman92) into this effort
because he is a key player in RIPE and EBONE and he is a co-chair
of the Intercontinental Engineering Planning Group (IEPG).
IESGは、アドレシングプランの創造が操作上の問題であると考えました。 したがって、IESGは、そのようなプランを開発するための努力を導くようにバーンハードStockman(IESG Operational Requirements Area Co-ディレクター)に頼みました。 バーンハードStockmanが彼がRIPEとEBONEの重要人物であり、Intercontinental Engineering Planning Group(IEPG)の共同議長であるので重要な国際的な入力(Stockman92)をこの努力に運び込む立場にあります。
A specific proposal [Gerich92] has now emerged. [Gerich92]
incorporates the views of the IETF, RIPE, IEPG, and the Federal
Engineering Planning group (FEPG).
明確な提案[Gerich92]は現在、現れました。 [Gerich92]はIETF、RIPE、IEPG、および連邦政府のEngineering Planningグループ(FEPG)の視点を取り入れます。
c. Pursue CIDR extensions to BGP in the BGP WG.
c。 BGP WGでCIDR拡張子をBGPまで追求してください。
This activity stated at the San Diego IETF meeting. A new BGP
specification, BGP4, incorporating the CIDR extensions, is now
available for public comment [Rekhter92a].
この活動はサンディエゴにIETFミーティングを述べました。 新しいBGP仕様(CIDR拡張子を取り入れるBGP4)は現在、パブリックコメント[Rekhter92a]に利用可能です。
Gross & Almquist [Page 12] RFC 1380 ROAD November 1992
グロスとAlmquist[12ページ]RFC1380道路1992年11月
d. Form a new WG to consider CIDR-related extensions to IDRP
(e.g., specify how run IDRP for IP inter-domain routing).
d。 新しいWGを形成して(例えば、IP相互ドメインルーティングにどのように走行IDRPを指定してくださいか)、CIDR関連の拡大をIDRPと考えてください。
e. Give careful consideration to how CIDR will be deployed in the
Internet.
e。 CIDRがインターネットでどう配備されるかに熟慮を与えてください。
This includes issues such as how to maintain address aggregation
across non-CIDR domains and how CIDR and various IGPs will need to
interact. Depending on the status of the combined CIDR
activities, the IESG may recommend forming a "CIDR Deployment WG",
along the same lines as the current BGP Deployment WG.
これは非CIDRドメインの向こう側にどのようにアドレス集合を主張するか、そして、CIDRと様々なIGPsが、どのように相互作用する必要があるかなどの問題を含んでいます。 結合したCIDR活動の状態によって、IESGは、「CIDR展開WG」を形成することを勧めるかもしれません、同じやり方で現在のBGP Deployment WGとして。
4.4 Regarding "Bigger Internet Addresses"
4.4 「より大きいインターネットアドレス」に関して
In April-May 1992, the IESG reviewed the various approaches emerging from the ROAD group activities -- e.g., "Simple CLNP" [Callon92a], "IP Encaps" [Hinden92], "CNAT" [Callon92b], and "Nimrod" [Chiappa91].
1992年4月-5月に、IESGはROADサークル活動から出て来る様々なアプローチを見直しました--例えば、「簡単なCLNP。」[Callon92a]「IP Encaps」[Hinden92]、"CNAT"[Callon92b]、および「ニムロデ」[Chiappa91]
(Note: These were the only proposals under serious consideration in this time period. Other proposals, namely "The P Internet Protocol (PIP)" [Tsuchiya92b] and "The Simple Internet Protocol (SIP)" [Deering92] have since been proposed. Following the San Diego IETF deliberations in March, "Simple CLNP" evolved into "TCP and UDP with Bigger Addresses (TUBA)", and "IP Encaps" evolved into "IP Address Encapsulation (IPAE)" [Hinden92].)
(以下に注意してください。 これらはこの期間の真剣な考慮での唯一の提案でした。 すなわち、他の提案、「Pインターネットプロトコル(種)」[Tsuchiya92b]と「簡単なインターネットプロトコル(一口)」[Deering92]は以来、提案されています。 3月にサンディエゴIETF熟考に続いて、「簡単なCLNP」は「より大きいアドレス(tuba)があるTCPとUDP」に発展しました、そして、「IP Encaps」は「IPアドレスカプセル化(IPAE)」[Hinden92]に発展しました。)
The "Simple CLNP" approach perhaps initially enjoyed more support than other approaches.
「簡単なCLNP」アプローチは初めは、恐らく他のアプローチより多くのサポートを楽しみました。
However, the consensus view in the IESG was that the full impact of transition to "Simple CLNP" (or to any of the proposed approaches) had not yet been explored in sufficient detail to make a final recommendation possible at this time.
しかしながら、IESGの大多数の見解は「簡単なCLNP」(または提案されたアプローチのどれかに)への変遷の完全な影響がまだこのとき最終勧告を可能にすることができるくらい詳細に調査されていなかったということでした。
The feeling in the IESG was that such important issues as
IESGの感じはあれほどそんなに重要な問題でした。
- impact on operational infrastructure,
- impact on current protocols (e.g., checksum computation
in TCP and UDP under any new IP-level protocol),
- deployment of new routing protocols,
- assignment of new addresses,
- impact on performance,
- ownership of change control
- effect of supporting new protocols, such as for address
resolution,
- effect on network management and security, and
- the costs to network operators and network users who must
- そして、操作上のインフラストラクチャで影響を与えてください--現在のプロトコル(例えば、どんな新しいIP-レベルプロトコルの下におけるTCPとUDPでのチェックサム計算)--性能の新しいルーティング・プロトコル--新しいアドレスの課題--衝撃の展開--変化コントロールの所有権--アドレス解決などの新しいプロトコルをサポートするという効果--ネットワークマネージメントとセキュリティへの効果で影響を与えてください、--、ネットワーク・オペレータとネットワーク利用者へのそうしなければならないコスト
Gross & Almquist [Page 13] RFC 1380 ROAD November 1992
グロスとAlmquist[13ページ]RFC1380道路1992年11月
be trained in the architecture and specifics of any new
protocols needed to be explored in more depth before a
decision of this magnitude should be made.
この大きさの決定をするべき前により多くの深さで探検するのに必要であるどんな新しいプロトコルの構造と詳細でも、訓練されてください。
At first the question seemed to be one of timing.
初めに、質問はタイミングについて1であるように思えました。
At the risk of oversimplifying some very wide ranging discussions, many in the IESG felt that if a decision had to be made *immediately*, then "Simple CLNP" might be their choice. However, they would feel much more comfortable if more detailed information was part of the decision.
いくつかの非常に広い及んでいる議論を単純化しすぎるというリスク、*すぐに決定をしなければならないなら次に、*、「簡単なCLNP」がそうすると感じられたIESGの多くでは、彼らの選択になってください。 しかしながら、彼らは、より詳細な情報が決定の一部であるならはるかに快適であると感じるでしょうに。
The IESG felt there needed to be an open and thorough evaluation of any proposed new routing and addressing architecture. The Internet community must have a thorough understanding of the impact of changing from the current IP architecture to a new one. The community needs to be confident that we all understand which approach has the most benefits for long-term internet growth and evolution, and the least impact on the current Internet.
IESGは、どんな提案された新しいルーティングとアドレッシング体系の開いていて徹底的な評価もあるのに必要であると感じました。 インターネットコミュニティには、現在のIP建築から新しいものに変化する衝撃の徹底的な理解がなければなりません。 共同体は、私たちが皆、どのアプローチが長期のインターネットの成長と発展のための最も多くの利益、および最少の影響力を現在のインターネットに持っているかを理解していると確信している必要があります。
The IESG considered what additional information and criteria were needed to choose between alternative approaches. We also considered the time needed for gathering this additional information and the amount of time remaining before it was absolutely imperative to make this decision (i.e., how much time do we have before we are in danger of running out of IP addresses *before* we could deploy a new architecture?).
IESGは、どんな追加情報と評価基準が代替的アプローチを選ぶのに必要であったかを考えました。 また、私たちは、時間がこの決定(私たちには、私たちに**私たちが新しい構造を配備できる前にIPアドレスを使い果たすという危険がある前にすなわち、どのくらいの時間がありますか?)をするのが絶対に必須になる前に残りながらこれを集めるのに追加情報と時間を必要としたと考えました。
This led the IESG to propose a specific set of selection criteria and information, and specific milestones and timetable for the decision.
これは、IESGが決定のために特定のセットの選択評価基準、情報、特定の重大事件、および時刻表を提案するように導きました。
The next section describes the milestones and timetable for choosing the approach for bigger Internet addresses.
次のセクションは、より大きいインターネット・アドレスのためのアプローチを選ぶための重大事件と時刻表について説明します。
The selection criteria referenced in the milestones are contained in Appendix B.
重大事件で参照をつけられる選択評価基準はAppendix Bに含まれています。
4.5 Milestones And Timetable For Making a Recommendation for "Bigger
Internet Addresses"
4.5 「より大きいインターネットアドレス」のために勧告するための重大事件と時刻表
In June, the IESG recommended that a call for proposals be made, with initial activities to begin at the July IETF in Boston, and with a strict timetable for reaching a recommendation coming out of the November IETF meeting [Gross92a].
6月に、IESGは、提案のための電話をかけることを勧めました、ボストン、そして、推薦に達するための厳しい時刻表が11月のIETFミーティングから出ていて7月のIETFで始める初期の活動で[Gross92a]。
Eventually, the call for proposals was made at the July meeting itself.
結局、7月のミーティング自体で提案のための電話をかけました。
Gross & Almquist [Page 14] RFC 1380 ROAD November 1992
グロスとAlmquist[14ページ]RFC1380道路1992年11月
A working group will be formed for each proposed approach. The charter of each WG will be to explore the criteria described in Appendix B and to develop a detailed plan for IESG consideration.
ワーキンググループはそれぞれの提案されたアプローチのために形成されるでしょう。 それぞれのWGの特許は、Appendix Bで説明された評価基準について調査して、IESGの考慮のための綿密な計画を開発することでしょう。
The WGs will be asked to submit an Internet-Draft prior to the November 1992 IETF, and to make presentations at the November IETF. The IESG and the IETF will review all submitted proposals and then the IESG will make a recommendation to the IAB following the November 1992 IETF meeting.
WGsは1992年11月のIETFの前でインターネット草稿を提出して、11月のIETFでプレゼンテーションを作るように頼まれるでしょう。 IESGとIETFはすべての提出された提案を見直すでしょう、そして、次に、IESGは1992年11月のIETFミーティングに続いて、推薦状をIABにするでしょう。
Therefore, the milestones and timetable for the IESG to reach a recommendation on bigger Internet addresses are:
したがって、IESGが、より大きいインターネット・アドレスにおける推薦に達する重大事件と時刻表は以下の通りです。
July 1992 -- Issue a call for proposals at the Boston IETF meeting
to form working groups to explore separate approaches for bigger
Internet addresses.
1992年7月--より大きいインターネット・アドレスのための別々のアプローチについて調査するためにワーキンググループを形成するボストンのIETFミーティングで提案のための呼び出しを発行してください。
August-November 1992 -- Proposed WGs submit charters, create
discussion lists, and begin their deliberations by email and/or
face- to-face meetings. Redistribute the IESG recommendation
(i.e., this memo). Public review, discussion, and modification as
appropriate of the "selection criteria" in Appendix B.
1992年8月-11月--提案されたWGsは表面へのメール、そして/または、表面ミーティングで特許を提出して、議論リストを作成して、彼らの熟考を始めます。 IESG推薦(すなわち、このメモ)を再配付してください。 Appendix Bで「選択評価基準」で同じくらい適切な公開レビュー、議論、および変更。
October 1992 -- By the end of October, each WG will be required to
submit a written description of the approach and how the criteria
are satisfied. This is to insure that these documents are
distributed as Internet-Drafts for public review well before the
November IETF meeting.
1992年10月--10月の終わりまでには、各WGが、アプローチと評価基準がどう満たされているかに関する書面による明細を提出するのに必要でしょう。 これは、これらのドキュメントが11月のIETFミーティングのよく前に公開レビューのためのインターネット草稿として配布されるのを保障するためのものです。
November 1992 -- Each WG will be given an opportunity to present
its findings in detail at the November 1992 IETF meeting. Based
on the written documents, the presentations, and public
discussions (by email and at the IETF), the IESG will forward a
recommendation to the IAB after the November IETF meeting.
1992年11月--1992年11月のIETFミーティングに詳細に調査結果を提示する機会を各WGに与えるでしょう。 文書に基づいて、プレゼンテーション、および公共の議論(メールとIETFの)、IESGは11月のIETFミーティングの後に推薦をIABに送るでしょう。
5. SUMMARY
5. 概要
The problems of Internet scaling and address exhaustion are fundamentally important to the continued health of the global Internet, and to the long-term success of such programs as the U.S. NREN and the European EBONE. Finding and embarking on a course of action is critical. However, the problem is so important that we need a deep understanding of the information and criteria described in Appendix B before a decision is made.
インターネットスケーリングとアドレス疲労困憊の問題は基本的に世界的なインターネットの長引く健康と、そして、U.S. NRENとヨーロッパのEBONEのようなプログラムの長期の成功に重要です。 行動を見つけて、始めるのは批判的です。 しかしながら、問題が非常に重要であるので、私たちは、決定をする前にAppendix Bで情報と評価基準の深い理解について説明する必要があります。
With this memo, the IESG re-affirms its earlier recommendation to the IAB that (a) we move CIDR forward in the IETF as described in section 4.3, and (b) that we encourage the exploration of other proposals for
このメモで、IESGは(a) 私たちがセクション4.3で説明されるようにIETFでCIDRを前方へ動かせるというIABへの以前の推薦、および私たちが他の提案の探検を奨励する(b)を再び断言します。
Gross & Almquist [Page 15] RFC 1380 ROAD November 1992
グロスとAlmquist[15ページ]RFC1380道路1992年11月
a bigger Internet address space according to the timetable in section 4.5.
セクション4.5の時刻表に従った、より大きいインターネットアドレス空間。
Appendix A. FOR MORE INFORMATION
詳しい情報のための付録A.
To become better acquainted with the issues and/or to follow the progress of these activities:
問題に詳しいほうがよくなって、これらの活動の進歩に続くように:
- Please see the documents in the Bibliography below.
- 以下のBibliographyのドキュメントを見てください。
- Join the Big-Internet mailing list where the general issues
are discussed (big-internet-request@munnari.oz.au).
- 一般答弁について議論するBig-インターネットメーリングリスト( big-internet-request@munnari.oz.au )を接合してください。
- Any new WG formed will have an open mailing list. Please feel
free to join each as they are announced on the IETF mailing
list. The current lists are:
- 形成されたどんな新しいWGも開いているメーリングリストを持つでしょう。 それらがIETFメーリングリストで発表されるように遠慮なくそれぞれを接合してください。 現在のリストは以下の通りです。
PIP: pip-request@thumper.bellcore.com
TUBA: tuba-request@lanl.gov
IPAE: ip-encaps-request@sunroof.eng.sun.com
SIP: sip-request@caldera.usc.edu
種: pip-request@thumper.bellcore.com チューバ: tuba-request@lanl.gov IPAE: ip-encaps-request@sunroof.eng.sun.com 一口: sip-request@caldera.usc.edu
- Attend the November IETF in Washington D.C. (where the WGs
will report and the IESG recommendation will begin formulating
its recommendation to the IAB).
- ワシントンDC(WGsが報告して、IESG推薦がIABに推薦を定式化し始めるところ)に11月のIETFに出席してください。
Note: In order to receive announcements of:
以下に注意してください。 以下の発表を受けます。
- future IETF meetings and agenda,
- new IETF working groups, and
- the posting of Internet-Drafts and RFCs,
- そして、今後のIETFミーティングと議題--新しいIETFワーキンググループ、--インターネット草稿とRFCsの任命
please send a request to join the IETF-Announcement mailing list (ietf-announce-request@nri.reston.va.us).
IETF-発表メーリングリスト( ietf-announce-request@nri.reston.va.us )を接合するという要求を送ってください。
Appendix B. INFORMATION AND SELECTION CRITERIA FOR "BIGGER INTERNET
ADDRESSES"
「より大きいインターネットアドレス」の付録B.情報と選択評価基準
This section describes the information and criteria which the IESG felt that any new routing and addressing proposal should supply. As the community has a chance to comment on these criteria, and as the IESG gets a better understanding of the issues relating to selection of a new routing and addressing architecture, this section may be revised and published in a separate document.
このセクションはIESGが感じた情報と評価基準について説明します。どんな新しいルーティングとも提案を記述するのは供するべきです。 共同体にはこれらの評価基準を批評する機会があって、IESGが問題の、より良い理解を新しいルーティングとアドレッシング体系の選択に関連させるとき、このセクションは、別々のドキュメントで改訂されて、発表されるかもしれません。
It is expected that every proposal submitted for consideration should address each item below on an point-by-point basis.
考慮のために提出されたあらゆる提案がポイントごとのベースに以下の各個条を記述するべきであると予想されます。
Gross & Almquist [Page 16] RFC 1380 ROAD November 1992
グロスとAlmquist[16ページ]RFC1380道路1992年11月
B.1 Description of the Proposed Scheme
提案された計画のB.1記述
A complete description of the proposed routing and addressing architecture should be supplied. This should be at the level of detail where the functionality and complexity of the scheme can be clearly understood. It should describe how the proposal solves the basic problems of IP address exhaustion and router resource overload.
提案されたルーティングとアドレッシング体系の完全な記述を供給するべきです。 これが明確に計画の機能性と複雑さを理解できるところに詳細のレベルにあるべきです。 それは提案がどうIPアドレス疲労困憊とルータリソースオーバーロードの基本的問題を解決するかを説明するべきです。
B.2 Changes Required
B.2変化が必要です。
All changes to existing protocols should be documented and new protocols which need to be developed and/or deployed should be specified and described. This should enumerate all protocols which are not currently in widespread operational deployment in the Internet.
既存のプロトコルへのすべての変化が記録されるべきであり、開発される、そして/または、配備される必要がある新しいプロトコルは、指定されて、説明されるべきです。 これはすべての現在広範囲の操作上の展開インターネットで中であるというわけではないプロトコルを列挙するべきです。
Changes should also be grouped by the devices and/or functions they affect. This should include at least the following:
また、変化はそれらが影響する装置、そして/または、機能によって分類されるべきです。 これは少なくとも以下を含むべきです:
- Protocol changes in hosts
- Protocol changes in exterior router
- Protocol changes in interior router
- Security and Authentication Changes
- Domain name system changes
- Network management changes
- Changes required to operations tools (e.g., ping, trace-
route, etc.)
- Changes to operational and administration
procedures
- ホストにおけるプロトコル変化--外のルータ--内部のルータにおけるプロトコル変化--セキュリティとAuthentication Changes--ドメイン名システム変更--ネットワークマネージメント変化におけるプロトコル変化--変化が操作ツール(例えば、ピング、跡のルートなど)に必要です。 - 操作上と管理手順への変化
The changes should also include if hosts and routers have their current IP addresses changed.
また、変化は、ホストとルータでそれらの現在のIPアドレスを変えるかどうかを含んでいるはずです。
The impact and changes to the existing set of TCP/IP protocols should be described. This should include at a minimum:
影響と変化は既存のセットのTCP/IPプロトコルに説明されるべきです。 これは最小限で以下を含むべきです。
- IP
- ICMP
- DNS
- ARP/RARP
- TCP
- UDP
- FTP
- RPC
- SNMP
- IP--ICMP--DNS--アルプ/RARP--TCP--UDP--FTP--RPC--SNMP
The impact on protocols which use IP addresses as data should be specifically addressed.
データとしてIPアドレスを使用するプロトコルへの影響は明確に記述されるべきです。
Gross & Almquist [Page 17] RFC 1380 ROAD November 1992
グロスとAlmquist[17ページ]RFC1380道路1992年11月
B.3 Implementation Experience
B.3実現経験
A description of implementation experience with the proposal should be supplied. This should include the how much of the proposal was implemented and hard it was to implement. If it was implemented by modifying existing code, the extent of the modifications should be described.
提案の実現経験の記述を供給するべきです。 これは、提案のどれくらい多くが実行されたかを含むべきです、そして、一生懸命、道具にはそれがありました。 それが既存のコードを変更することによって実行されるなら、変更の範囲は説明されるでしょうに。
B.4 Large Internet Support
B.4の大きいインターネットサポート
The proposal should describe how it will scale to support a large internet of a billion networks. It should describe how the proposed routing and addressing architecture will work to support an internet of this size. This should include, as appropriate, a description of the routing hierarchy, how the routing and addressing will be organized, how different layers of the routing interact (e.g., interior and exterior, or L1, L2, L3, etc.), and relationship between addressing and routing.
提案はそれがどう10億のネットワークの大きいインターネットについて合わせて調整するかをサポートに説明するべきです。 それは提案されたルーティングとアドレッシング体系がこのサイズのインターネットを支持するためにどう利くかを説明するべきです。 これは適宜アドレシングとルーティングとのルーティング階層構造の記述、ルーティングとアドレシングがどう組織化されるだろうか、そして、ルーティングの異なった層がどう相互作用するか、そして、(例えば、内部と外部や、L1、L2、L3など)および関係を含むべきです。
The addressing proposed should include a description of how addresses will be assigned, who owns the addresses (e.g., user or service provider), and whether there are restrictions in address assignment or topology.
提案されたアドレシングはアドレスがどのように割り当てられるだろうか、そして、だれがアドレス(例えば、ユーザかサービスプロバイダー)を所有するか、そして、制限がアドレス課題かトポロジーにあるかに関する記述を含むべきです。
B.5 Syntax and semantics of names, identifiers and addresses
名前、識別子、およびアドレスのB.5構文と意味論
Proposals should address the manner in which data sources and sinks are identified and addressed, describe how current domain names and IP addresses would be used/translated/mapped in their scheme, how proposed new identifier and address fields and semantics are used, and should describe the issues involved in administration of these id and address spaces according to their proposal. The deployment plan should address how these new semantics would be introduced and backward compatibility maintained.
提案はデータ送信端末と流し台が特定されて、記述される方法を記述するべきであり、現在のドメイン名とIPアドレスがそれらの計画で使用されるか、翻訳される、またはどう写像されるだろうかを説明してください、提案された新しい識別子、アドレス・フィールド、および意味論はどう使用されていて、彼らの提案に従ってこれらのイドとアドレス空間の管理にかかわる問題について説明するべきであるか。 展開プランはこれらの新しい意味論がどう維持された導入されて後方の互換性であるだろうかを記述するべきです。
Any overlays in the syntax of these protocol structures should be clearly identified and conflicts resulting from syntactic overlay of functionality should be clearly addressed in the discussion of the impact on administrative assignment.
これらのプロトコル構造の構文によるどんなオーバレイも明確に特定されるべきです、そして、機能性の構文のオーバレイから生じる闘争は管理課題についての衝撃の議論で明確に記述されるべきです。
B.6 Performance Impact
B.6パフォーマンス衝撃
The performance impact of the new routing and addressing architecture should be evaluated. It should be compared against the current state of the art with the current IP. The performance evaluation for routers and hosts should include packets-per-second and memory usage projections, and bandwidth usage for networks. Performance should be evaluated for both high speed speed and low speed lines.
新しいルーティングとアドレッシング体系の性能影響は評価されるべきです。 現在のIPと共に芸術の現状に対して比較されるべきです。 ルータとホストのための業績評価は1秒あたりのパケットとメモリ使用量映像、およびネットワークのための帯域幅用法を含むべきです。 パフォーマンスは高速速度と低速線の両方のために評価されるべきです。
Gross & Almquist [Page 18] RFC 1380 ROAD November 1992
グロスとAlmquist[18ページ]RFC1380道路1992年11月
Performance for routers (table size and computational load) and network bandwidth consumption should be projected based on the following projected data points:
ルータ(テーブル・サイズとコンピュータの負荷)のためのパフォーマンスとネットワーク回線容量消費は以下の映し出されたデータポイントに基づいて予測されるべきです:
-Domains 10^3 10^4 10^5 10^6 10^7 10^8
-Networks 10^4 10^5 10^6 10^7 10^8 10^9
-Hosts 10^6 10^7 10^8 10^9 10^10 10^11
-ドメイン10^3 10^4、10^5 10^6 10^7 10^8つのネットワーク10^4 10^5 10^6 10^7 10^8 10^9が10^6 10^7 10^8 10^9 10^を接待する、10 10^11
B.7 Support for TCP/IP hosts than do not support the new architecture
B.7はTCP/IPのために新しい構造をサポートしないよりホストを支持します。
The proposal should describe how hosts which do not support the new architecture will be supported -- whether they receive full services and can communicate with the whole Internet, or if they will receive limited services. Also, describe if a translation service be provided between old and new hosts? If so, where will be this be done.
提案は、新しい構造をサポートしないホストがどうしたら彼らがフルサービスを受けるか否かに関係なく、支持されて、全体のインターネットで交信できるか、そして、またはそれらが限られたサービスを受けるかどうか説明するべきです。 また、翻訳サービスが老人の間に提供されて新しいホストであるなら、説明しますか? そうだとすれば、どこがこれになるだろうか。します。
B.8 Effect on User Community
ユーザーコミュニティへのB.8効果
The large and growing installed base of IP systems comprises people, as well as software and machines. The proposal should describe changes in understanding and procedures that are used by the people involved in internetworking. This should include new and/or changes in concepts, terminology, and organization.
IPシステムの大きくて増加しているインストールされたベースは人々、ソフトウェア、およびマシンを含みます。 提案はインターネットワーキングにかかわる人々によって用いられる理解と手順における変化について説明するべきです。 これは、新しい状態で包含するべきである、そして/または、概念、用語、および組織で変化します。
B.9 Deployment Plan Description
B.9展開プラン記述
The proposal should include a deployment plan. It should include the steps required to deploy it. Each step should include the devices and protocols which are required to change and what benefits are derived at each step. This should also include at each step if hosts and routers are required to run the current and proposed internet protocol.
提案は展開プランを含むべきです。 それはそれを配備するのに必要であるステップを含むべきです。 各ステップは変化するのに必要である装置とプロトコルを含むべきです、そして、利益を得ることは各ステップで引き出されます。 また、これは、各ステップにホストとルータが現在の、そして、提案されたインターネットプロトコルを走らせるのに必要であるかどうかを含むべきです。
A schedule should be included, with justification showing that the schedule is realistic.
スケジュールはスケジュールが現実的であることを示す正当化で含まれるべきです。
B.10 Security Impact
B.10セキュリティ衝撃
The impact on current and future security plans should be addressed. Specifically do current security mechanisms such as address and protocol port filtering work in the same manner as they do today, and what is the effect on security and authentication schemes currently under development.
現在の、そして、将来の警備計画への影響は記述されるべきです。 今日、して、セキュリティと認証への効果であることが現在開発中に計画されるように、明確にアドレスなどの現在のセキュリティー対策をしてください、そして、同じ方法で仕事をフィルターにかけるポートについて議定書の中で述べてください。
B.11 Future Evolution
B.11の今後の発展
The proposal should describe how it lays a foundation for solving
提案はそれがどう解決の基礎を築くかを説明するべきです。
Gross & Almquist [Page 19] RFC 1380 ROAD November 1992
グロスとAlmquist[19ページ]RFC1380道路1992年11月
emerging internet problems such as security/authentication, mobility, resource allocation, accounting, high packet rates, etc.
セキュリティ/認証、移動性、資源配分、会計、高いパケットレートなどのインターネット問題として、現れます。
Appendix C. BIBLIOGRAPHY
付録C.図書目録
-Documents and Information from IETF/IESG:
-IETF/IESGからのドキュメントと情報:
[Ford92] Ford, P., and P. Gross, "Routing And Addressing Considerations", Proceedings of the Twenty-Third IETF, March 1992.
[Ford92] フォード、P.、およびP.グロス、「問題を発送して、記述します」、第23IETF、1992年3月の議事。
[Gross92] Gross, P., "Chair's Message and Minutes of the Open IETF Plenary", Proceedings of the Twenty-Third IETF, March 1992.
P.の、そして、「メッセージと数分について開く議長IETF絶対的な[Gross92]グロス、」、第23IETF、3月1992の議事
[Gross92a] Gross, P., "IESG Deliberations on Routing and Addressing", Electronic mail message to the Big-Internet mailing list, June 1992.
[Gross92a] グロス、P.、「ルート設定とアドレシングにおけるIESG熟考」とElectronicは、メッセージをBig-インターネットメーリングリスト、1992年6月まで郵送します。
-Documents directly resulting from the ROAD group:
-直接ROADから生じるドキュメントが分類されます:
[Fuller92] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cisco, Merit, OARnet, June 1992.
[Fuller92] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「スーパーネッティング:」 「Address AssignmentとAggregation Strategy」、RFC1338、BARRNet、コクチマス、Merit、OARnet、6月1992日
[Hinden92] Hinden, B., "New Scheme for Internet Routing and Addressing (ENCAPS)", Email message to Big-Internet mailing list, March 16, 1992.
[Hinden92] Hinden、B.、「インターネットルート設定の新しい計画、(ENCAPS)を記述すること」はBig-インターネットメーリングリストへのメッセージ、1992年3月16日をメールします。
[Callon92a] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing", RFC 1347, DEC, June 1992
[Callon92a]Callon、R.、「より大きいのがあるTCPとUDPは(tuba)、インターネットアドレシングとルート設定のための簡単な提案を記述します」、RFC1347、1992年12月、6月
[Deering92] Deering, S., "City Codes: An Alternative Scheme for OSI NSAP Allocation in the Internet", Email message to Big-Internet mailing list, January 7, 1992.
[Deering92] デアリング、S.、「市は以下をコード化します」。 「インターネットのオウシNSAP AllocationのためのAlternative Scheme」、Big-インターネットメーリングリストへのメールメッセージ、1992年1月7日。
[Callon92b] CNAT
[Callon92b]CNAT
-Related Documents:
-関連ドキュメント:
[Hinden92b] Hinden, R., and D. Crocker, "A Proposal for IP Address Encapsulation (IPAE): A Compatible version of IP with Large Addresses", Work in Progress, June 1992.
[Hinden92b] Hinden、R.、およびD.クロッカー、「IPのための提案はカプセル化(IPAE)を記述します」。 「Large AddressesとIPのCompatibleバージョン」、Progress、1992年6月のWork。
[Deering92b] Deering, S., "The Simple Internet Protocol", Big- Internet mailing list.
[Deering92b] デアリング、S.、「簡単なインターネットプロトコル」Bigインターネットメーリングリスト。
[Stockman92] Karrenberg, D., and B. Stockman, "A Proposal for a Global Internet Addressing Scheme", Work in Progress, May 1992.
D.、およびB.牧畜業者、「グローバルなインターネットアドレシング計画のための提案」という[Stockman92]Karrenbergは進歩、1992年5月に働いています。
Gross & Almquist [Page 20] RFC 1380 ROAD November 1992
グロスとAlmquist[20ページ]RFC1380道路1992年11月
[Rekhter92] Rekhter, Y., and T. Li, "Guidelines for IP Address Allocation", Work in Progress, May 1992.
[Rekhter92] Rekhter、Y.、およびT.李、「IPアドレス配分のためのガイドライン」は進歩、1992年5月に働いています。
[Rekhter92b] Rekhter, Y., and T. Li, "The Border Gateway Protocol (Version 4)", Work in Progress, September 1992.
Y.、およびT.李、「ボーダ・ゲイトウェイ・プロトコル(バージョン4)」という[Rekhter92b]Rekhterは進歩、1992年9月に働いています。
[Rekhter92c] Rekhter, Y., and P. Gross, "Application of the Border Gateway Protocol", Work in Progress, September 1992.
[Rekhter92c] Rekhter、Y.、およびP.グロス、「ボーダ・ゲイトウェイ・プロトコルの応用」は進歩、1992年9月に働いています。
[Gerich92] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1366, Merit, October 1992.
[Gerich92] Gerich、「IP管理アドレス空間のためのガイドライン」(RFC1366)が1992年10月に値するE.。
[Solen92] Solensky, F., and F. Kastenholz, "A Revision to IP Address Classifications", Work in Progress, March 1992.
[Solen92] Solensky、F.、およびF.Kastenholz、「IPアドレス分類への改正」が進歩、1992年3月に働いています。
[Wang92] Wany, Z., and J. Crowcroft, "A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion", RFC 1335, University College London, May 1992.
[Wang92] Wany、Z.、およびJ.クロウクロフト、「2層がインターネットに構造を記述します」。 「アドレス空間疲労困憊の問題の解決」、RFC1335、ユニバーシティ・カレッジロンドンは1992がそうするかもしれません。
[Callon91] Callon, R., Gardner, E., and R. Colella, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, July 1991.
[Callon91] Callon、R.、ガードナー、E.、およびR.Colella、「インターネットのオウシNSAP Allocationのためのガイドライン」、RFC1237、NIST、斜め継ぎ、12月(1991年7月)。
[Tsuchiya92a] Tsuchiya, P., "The IP Network Address Translator (NAT): Preliminary Design", Work in Progress, April 1991.
[Tsuchiya92a]Tsuchiya、P.、「IPネットワークは翻訳者(NAT)に演説します」。 「予備のデザイン」、進行中の仕事、1991年4月。
[Tsuchiya92b] Tsuchiya, P., "The 'P' Internet Protocol", Work in Progress, May 1992.
P.、P'インターネットプロトコル」という[Tsuchiya92b]Tsuchiyaは進歩、1992年5月に働いています。
[Chiappa91] Chiappa, J., "A New IP Routing and Addressing Architecture", Work in Progress, July 1991.
J.と、「新しいIPルート設定とアドレッシング体系」という[Chiappa91]Chiappaは進歩、1991年7月に働いています。
[Clark91] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Towards the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December 1991.
[Clark91] クラークとD.とチェーピンとL.とサーフとV.とブレーデン、R.とR.趣味、「今後のインターネット建築」、RFC1287、MIT、BBN、CNRI、ISI、UCDavis(1991年12月)。
Security Considerations
セキュリティ問題
Security issues are discussed in sections 4.4, B.2, B.10, and B.11.
安全保障問題はセクション4.4、B.2、B.10、およびB.11で論じられます。
Gross & Almquist [Page 21] RFC 1380 ROAD November 1992
グロスとAlmquist[21ページ]RFC1380道路1992年11月
Authors' Addresses
作者のアドレス
Phillip Gross, IESG Chair Advanced Network & Services 100 Clearbrook Road Elmsford, NY
フィリップGross、IESGの議長の高度なネットワーク、およびサービス100Clearbrook Roadエルムスフォード(ニューヨーク)
Phone: 914-789-5300 EMail: pgross@ans.net
以下に電話をしてください。 914-789-5300 メールしてください: pgross@ans.net
Philip Almquist Stanford University Networking Systems Pine Hall 147 Stanford, CA 94305
カリフォルニア 松のHall147スタンフォード、フィリップAlmquistスタンフォード大学ネットワークシステム94305
Phone: (415) 723-2229 EMail: Almquist@JESSICA.STANFORD.EDU
以下に電話をしてください。 (415) 723-2229 メールしてください: Almquist@JESSICA.STANFORD.EDU
Gross & Almquist [Page 22]
グロスとAlmquist[22ページ]
一覧
スポンサーリンク
