Network Working Group R. Atkinson, Ed.
Request for Comments: 3869 S. Floyd, Ed.
Category: Informational Internet Architecture Board
August 2004
IAB Concerns and Recommendations
Regarding Internet Research and Evolution
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research.
この文書では、進行中の研究は、インターネットインフラの進化を促進するために必要とされるというIABの懸念を議論し、その一貫性のある、十分な非商業的資金は、そのような研究を可能にするために必要とされています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document Organization. . . . . . . . . . . . . . . . . . 2
1.2. IAB Concerns . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Contributions to this Document . . . . . . . . . . . . . 4
2. History of Internet Research and Research Funding. . . . . . . 4
2.1. Prior to 1980. . . . . . . . . . . . . . . . . . . . . . 4
2.2. 1980s and early 1990s. . . . . . . . . . . . . . . . . . 5
2.3. Mid-1990s to 2003. . . . . . . . . . . . . . . . . . . . 6
2.4. Current Status . . . . . . . . . . . . . . . . . . . . . 6
3. Open Internet Research Topics. . . . . . . . . . . . . . . . . 7
3.1. Scope and Limitations. . . . . . . . . . . . . . . . . . 7
3.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Domain Name System (DNS). . . . . . . . . . . . 8
3.2.2. New Namespaces. . . . . . . . . . . . . . . . . 9
3.3. Routing. . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Inter-domain Routing. . . . . . . . . . . . . . 10
3.3.2. Routing Integrity . . . . . . . . . . . . . . . 11
3.3.3. Routing Algorithms. . . . . . . . . . . . . . . 12
3.3.4. Mobile and Ad-Hoc Routing . . . . . . . . . . . 13
3.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Formal Methods. . . . . . . . . . . . . . . . . 14
3.4.2. Key Management. . . . . . . . . . . . . . . . . 14
3.4.3. Cryptography. . . . . . . . . . . . . . . . . . 15
3.4.4. Security for Distributed Computing. . . . . . . 15
3.4.5. Deployment Considerations in Security . . . . . 15
3.4.6. Denial of Service Protection. . . . . . . . . . 16
3.5. Network Management . . . . . . . . . . . . . . . . . . . 16
3.5.1. Managing Networks, Not Devices. . . . . . . . . 16
3.5.2. Enhanced Monitoring Capabilities. . . . . . . . 17
3.5.3. Customer Network Management . . . . . . . . . . 17
3.5.4. Autonomous Network Management . . . . . . . . . 17
3.6. Quality of Service . . . . . . . . . . . . . . . . . . . 17
3.6.1. Inter-Domain QoS Architecture . . . . . . . . . 18
3.6.2. New Queuing Disciplines . . . . . . . . . . . . 19
3.7. Congestion Control . . . . . . . . . . . . . . . . . . . 19
3.8. Studying the Evolution of the Internet Infrastructure. . 20
3.9. Middleboxes. . . . . . . . . . . . . . . . . . . . . . . 21
3.10. Internet Measurement . . . . . . . . . . . . . . . . . . 21
3.11. Applications . . . . . . . . . . . . . . . . . . . . . . 22
3.12. Meeting the Needs of the Future. . . . . . . . . . . . . 22
3.13. Freely Distributable Prototypes. . . . . . . . . . . . . 23
4. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
7. Informative References . . . . . . . . . . . . . . . . . . . . 24
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
This document discusses the history of funding for Internet research, expresses concern about the current state of such funding, and outlines several specific areas that the IAB believes merit additional research. Current funding levels for Internet research are not generally adequate, and several important research areas are significantly underfunded. This situation needs to be rectified for the Internet to continue its evolution and development.
この文書は、インターネット調査のための資金調達の歴史を説明し、そのような資金調達の現在の状態に関する懸念を表明し、IABはメリット追加の研究を信じているいくつかの特定の領域の概要を説明します。インターネット調査のために、現在の資金レベルは、一般的に適切ではない、といくつかの重要な研究分野は大幅に積立不足しています。この状況は、その進化と発展を続けるために、インターネットのために整流する必要があります。
The first part of the document is a high-level discussion of the history of funding for Internet research to provide some historical context to this document. The early funding of Internet research was largely from the U.S. government, followed by a period in the second half of the 1990s of commercial funding and of funding from several governments. However, the commercial funding for Internet research has been reduced due to the recent economic downturn.
文書の最初の部分は、この文書には、いくつかの歴史的背景を提供するために、インターネット調査のための資金調達の歴史のハイレベルな議論です。インターネット調査の早期の資金調達は、市販の資金調達のいくつかの政府からの資金の1990年代後半の期間に続いて、米政府から大きくしました。しかし、インターネット調査のため、市販の資金は昨今の経済不況に縮小されています。
The second part of the document provides an incomplete set of open Internet research topics. These are only examples, intended to illustrate the breadth of open research topics. This second section supports the general thesis that ongoing research is needed to further the evolution of the Internet infrastructure. This includes research on the medium-time-scale evolution of the Internet infrastructure as well as research on longer-time-scale grand challenges. This also includes many research issues that are already being actively investigated in the Internet research community.
文書の第二部は、オープンなインターネットの研究テーマの不完全なセットを提供します。これらは、オープン研究テーマの幅広さを説明することを意図したもののみ例です。この2番目のセクションでは、進行中の研究は、インターネットインフラの進化を促進するために必要とされるという一般的な論文をサポートしています。これは、中規模の時間スケールのインターネットインフラの進化だけでなく、より長い時間スケールの壮大な課題についての研究の研究を含んでいます。また、これはすでに積極的にインターネットの研究コミュニティに検討されている多くの研究課題が含まれています。
Areas that are discussed in this section include the following: naming, routing, security, network management, and transport. Issues that require more research also include more general architectural issues such as layering and communication between layers. In addition, general topics discussed in this section include modeling, measurement, simulation, test-beds, etc. We are focusing on topics that are related to the IETF and IRTF (Internet Research Task Force) agendas. (For example, Grid issues are not discussed in this document because they are addressed through the Global Grid Forum and other Grid-specific organizations, not in the IETF.)
このセクションで説明されているエリアには次のものがあります。命名、ルーティング、セキュリティ、ネットワーク管理、及び輸送を。より多くの研究が必要な問題も、そのような層の間でレイヤーや通信など、より一般的な建築の問題があります。また、このセクションで説明する一般的なトピックは、私たちは、IETFとIRTF（インターネットリサーチタスクフォース）の議題に関連するトピックに焦点を当てている、モデリング、測定、シミュレーション、テストベッドなどが含まれます。 （これらはグローバル・グリッド・フォーラムおよびその他のグリッド特定の組織を通じてではなく、IETFで対処されているので、例えば、グリッドの問題は、この文書で説明されていません。）
Where possible, the examples in this document point to separate documents on these issues, and only give a high-level summary of the issues raised in those documents.
可能な場合には、この文書の時点での例は、これらの問題についての文書を分離し、そしてドキュメントのみに提起された問題の高レベルな概要を与えます。
In the aftermath of September 11 2001, there seems to be a renewed interest by governments in funding research for Internet-related security issues. From [Jackson02]: "It is generally agreed that the security and reliability of the basic protocols underlying the Internet have not received enough attention because no one has a proprietary interest in them".
2001年9月11日の余波で、インターネット関連のセキュリティ問題のための資金調達の研究では政府による新たな関心があるように思われます。 [Jackson02]から：「一般的に誰がそれらで所有権を持っていないため、インターネットの基礎となる基本的なプロトコルのセキュリティと信頼性が十分な注意を受けていないことが合意されました」。
That quote brings out a key issue in funding for Internet research, which is that because no single organization (e.g., no single government, software company, equipment vendor, or network operator) has a sense of ownership of the global Internet infrastructure, research on the general issues of the Internet infrastructure are often not adequately funded. In our current challenging economic climate, it is not surprising that commercial funding sources are more likely to fund that research that leads to a direct competitive advantage.
その引用は、単一の組織（例えば、単一の政府、ソフトウェア会社、機器ベンダー、またはネットワークオペレータ）ので、することは世界的なインターネットインフラストラクチャの所有権の感覚を持っていることであるインターネット調査のための資金調達の重要な問題を、引き出しの研究インターネットインフラストラクチャの一般的な問題は、多くの場合、十分な資金を供給されていません。私たちの現在の厳しい経済情勢の中で、商業的資金源が直接競争優位につながるという研究に資金を提供する可能性が高いことは驚くべきことではありません。
The principal thesis of this document is that if commercial funding is the main source of funding for future Internet research, the future of the Internet infrastructure could be in trouble. In addition to issues about which projects are funded, the funding source can also affect the content of the research, for example, towards or against the development of open standards, or taking varying degrees of care about the effect of the developed protocols on the other traffic on the Internet.
このドキュメントの主な論文は、市販の資金は、将来のインターネット調査のための資金の主な情報源であれば、インターネットインフラの将来はトラブルになる可能性があることです。プロジェクトが資金を提供されているかについての問題に加えて、資金源はまた、例えば、方やオープンな標準の開発に対して、研究の内容に影響を与えることができ、または他の開発されたプロトコルの効果についてのケアの様々な程度を取りますインターネット上のトラフィック。
At the same time, many significant research contributions in networking have come from commercial funding. However, for most of the topics in this document, relying solely on commercially-funded research would not be adequate. Much of today's commercial funding is focused on technology transition, taking results from non-commercial research and putting them into shipping commercial products. We have not tried to delve into each of the research issues below to discuss, for each issue, what are the potentials and limitations of commercial funding for research in that area.
同時に、ネットワークの多くの重要な研究の貢献は、市販の資金から来ています。しかし、このドキュメントのトピックのほとんどのため、商業的資金による研究のみに依存することは適切ではないでしょう。今日の商業資金の多くは非商業的な研究からの結果を取り、商用製品の出荷にそれらを入れて、技術の変化に焦点を当てています。私たちは、それぞれの問題のために、その地域での研究のための商業資金の電位と限界は何をしている、議論するには、以下の研究課題のそれぞれを掘り下げしようとしていません。
On a more practical note, if there was no commercial funding for Internet research, then few research projects would be taken to completion with implementations, deployment, and follow-up evaluation.
インターネット調査のための商業的な資金がなかった場合は、より実用的なノートでは、その後、いくつかの研究プロジェクトは、実装、展開、およびフォローアップ評価で完全に取られるでしょう。
While it is theoretically possible for there to be too much funding for Internet research, that is far from the current problem. There is also much that could be done within the network research community to make Internet research more focused and productive, but that would belong in a separate document.
インターネット調査のためにあまりにも多くの資金があっすることが理論的には可能ですが、それははるかに現在の問題からです。そこインターネット調査より集中し、生産性を高めるために、ネットワークの研究コミュニティの中で行うことができるそれだけでもありますが、それは別の文書に属します。
A number of people have directly contributed text for this document, even though, following current conventions, the official RFC author list includes only the key editors of the document. The Acknowledgements section at the end of the document thanks other people who contributed to this document in some form.
人々の数は直接的にもかかわらず、このドキュメントのテキストを貢献してきた、現在の規則に従って、公式RFCの作者リストには、ドキュメントの唯一の主要な編集者を含んでいます。何らかの形でこの文書に貢献した文書のおかげで、他の人の最後の謝辞セクション。
Most of the early research into packet-switched networks was sponsored by the U.S. Defense Advanced Research Projects Agency (DARPA) [CSTB99]. This includes the initial design, implementation, and deployment of the ARPAnet connecting several universities and other DARPA contractors. The ARPAnet originally came online in the late 1960s. It grew in size during the 1970s, still chiefly with DARPA funding, and demonstrated the utility of packet-switched networking.
パケット交換ネットワークへの初期の研究のほとんどは、[CSTB99]米国国防高等研究計画庁（DARPA）が主催ました。これにはいくつかの大学や他のDARPAの請負業者を結ぶARPAnetの初期の設計、実装、および展開を含んでいます。 ARPAnetのは、もともと1960年代後半にオンラインになりました。これは、DARPAの資金で、まだ主に、1970年代のサイズに成長し、パケット交換ネットワークの有用性を実証しました。
DARPA funding for Internet design started in 1973, just four years after the initial ARPAnet deployment. The support for Internet design was one result of prior DARPA funding for packet radio and packet satellite research. The existence of multiple networks (ARPAnet, packet radio, and packet satellite) drove the need for internetworking research. The Internet arose in large measure as a consequence of DARPA research funding for these three networks -- and arise only incidentally from the commercially-funded work at Xerox PARC on Ethernet.
インターネット設計のためのDARPAの資金はわずか4年最初のARPAnetの展開後、1973年に開始しました。インターネット設計のためのサポートは、パケット無線とパケット衛星研究のための前DARPAの資金調達の一つの結果でした。複数のネットワーク（ARPAnetの、パケット無線、およびパケット衛星）の存在は、研究をインターネットワーキングのための必要性を運転しました。インターネットは、これらの3つのネットワークのためのDARPAの研究資金の結果として大規模な措置で発生した - とイーサネット上のゼロックスPARCで商業的に出資の仕事からのみ、偶然に生じます。
The ARPAnet converted to the Internet Protocol (IP) on January 1, 1983, approximately 20 years before this document was written. Throughout the 1980s, the U.S. Government continued strong research and development funding for Internet technology. DARPA continued to be the key funding source, but was supplemented by other DoD (U.S. Department of Defense) funding (e.g., via the Defense Data Network (DDN) program of the Defense Communication Agency (DCA)) and other U.S. Government funding (e.g., U.S. Department of Energy (DoE) funding for research networks at DoE national laboratories, (U.S.) National Science Foundation (NSF) funding for academic institutions). This funding included basic research, applied research (including freely distributable prototypes), the purchase of IP-capable products, and operating support for the IP-based government networks such as ARPAnet, ESnet, MILnet, the NASA Science Internet, and NSFnet.
ARPAnetのは、この文書が書かれた約20年前、1983年1月1日にインターネットプロトコル（IP）に変換します。 1980年代を通じて、米国政府は、インターネット技術のための強力な研究開発資金を続けました。 DARPAは、その他の米国政府の資金調達（防衛通信局（DCA）の国防データ・ネットワーク（DDN）プログラムを経由して、例えば）キー資金源であり続けたが、他のDoD（米国国防総省）の資金で補充した（たとえば、 、米国エネルギー省の学術機関のための（DOE）エネルギー省国立研究所での研究ネットワークのための資金調達、（米国）国立科学財団（NSF）の資金調達）。この資金は、基礎研究を含め、IP対応製品の購入を（自由に配布プロトタイプを含む）、応用研究、そして、そのようなARPAnetの、ESnet、MILNET、NASA科学インターネット、およびNSFnetのようIPベースの政府のネットワークの動作をサポート。
During the 1980s, the U.S. DoD desired to leave the business of providing operational network services to academic institutions, so funding for most academic activities moved over to the NSF during the decade. NSF's initial work included sponsorship of CSnet in 1981. By 1986, NSF was also sponsoring various research projects into networking (e.g., Mills' work on Fuzzballs). In the late 1980s, NSF created the NSFnet backbone and sponsored the creation of several NSF regional networks (e.g., SURAnet) and interconnections with several international research networks. NSF also funded gigabit networking research, through the Corporation for National Research Initiatives (CNRI), starting in the late 1980s. It is important to note that the NSF sponsorship was focused on achieving core NSF goals, such as connecting scientists at leading universities to NSF supercomputing centers. The needs of high-performance remote access to supercomputers drove the overall NSFnet performance. As a side effect, this meant that students and faculty at those universities enjoyed a relatively high-performance Internet environment. As those students graduated, they drove both commercial use of the Internet and the nascent residential market. It is no accident that this was the environment from which the world wide web emerged.
1980年代に、米国国防総省は、学術機関に運用ネットワークサービスを提供するビジネスを残すことが望ましいので、ほとんどの学術活動のための資金は、十年の間、NSFに上に移動しました。 NSFの初期の作品は、1986年まで1981年CSNETのスポンサーシップを含め、NSFはまた、ネットワークにさまざまな研究プロジェクトを後援した（例えば、Fuzzballs上Millsの仕事）。 1980年代後半には、NSFはNSFnetのバックボーンを作成し、いくつかのNSF地域ネットワーク（例えば、SURAnet）といくつかの国際研究ネットワークとの相互接続の作成を後援しました。 NSFはまた、1980年代後半に始まり、国立研究イニシアティブ株式会社（CNRI）を介して、ギガビットネットワーク研究に資金を提供します。 NSFのスポンサーは、このようなNSFのスーパーコンピューティングセンターに一流大学の科学者を結ぶなどのコアNSFの目標を、達成することに集中していたことに注意することが重要です。スーパーコンピュータの高性能のリモートアクセスのニーズが全体のNSFnetのパフォーマンスを運転しました。副作用として、これはそれらの大学の学生と教員が比較的高性能なインターネット環境を楽しんだことを意味しました。これらの学生が卒業したように、彼らはインターネットの両方の商用利用と発生期の住宅市場を運転しました。これはワールドワイドウェブが登場し、そこから環境だったことは偶然ではありません。
Most research funding outside the U.S. during the 1980s and early 1990s was focused on the ISO OSI networking project or on then-new forms of network media (e.g., wireless, broadband access). The European Union was a significant source of research funding for the networking community in Europe during this period. Some of the best early work in gigabit networking was undertaken in the UK and Sweden.
1980年代から1990年代の米国外のほとんどの研究資金は、ISO OSIネットワーキングプロジェクトやネットワークメディア（例えば、ワイヤレス、ブロードバンドアクセス）の当時の新しい形態に焦点を当てました。欧州連合（EU）は、この期間中にヨーロッパでのネットワークコミュニティのための研究資金の重要な源でした。ギガビットネットワークで最高の初期の作品のいくつかは、英国とスウェーデンで行われました。
Starting in the middle 1990s, U.S. Government funding for Internet research and development was significantly reduced. The premise for this was that the growing Internet industry would pay for whatever research and development that was needed. Some funding for Internet research and development has continued in this period from European and Asian organizations (e.g., the WIDE Project in Japan [WIDE]). Reseaux IP Europeens [RIPE] is an example of market-funded networking research in Europe during this period.
途中、1990年代以降、インターネットの研究開発のための米国政府の資金が大幅に減少しました。このための前提は、成長しているインターネット業界が必要だったものは何でも研究開発のために支払うことになるということでした。インターネットの研究開発のためのいくつかの資金は、欧州やアジアの団体から、この期間中に継続している（例えば、日本ではWIDEプロジェクト[WIDE]）。 Reseaux IP Europeens [RIPE]は、この期間中のヨーロッパにおける市場の資金によるネットワーキング研究の一例です。
Experience during this period has been that commercial firms have often focused on donating equipment to academic institutions and promoting somewhat vocationally-focused educational projects. Many of the commercially-funded research and development projects appear to have been selected because they appeared likely to give the funding source a specific short-term economic advantage over its competitors. Higher risk, more innovative research proposals generally have not been funded by industry. A common view in Silicon Valley has been that established commercial firms are not very good at transitioning cutting edge research into products, but were instead good at buying small startup firms who had successfully transitioned such cutting edge research into products. Unfortunately, small startup companies are generally unable financially to fund any research themselves.
この期間中の経験は、商業企業は、多くの場合、学術機関に機器を寄贈し、ややvocationallyに焦点を当てた教育プロジェクトの推進に焦点を当てているということでした。商業的資金による研究開発プロジェクトの多くは、その競合他社に対する資金源に特定の短期的な経済的利点を与える可能性が現われたので、選択されているように見えます。高いリスクは、より革新的な研究提案は、一般的に、業界によって資金を供給されていません。シリコンバレーでの共通のビューは、商業企業を設立してきたその製品に最先端の研究の移行で非常に良いではありませんが、成功した製品に、このような最先端の研究を移行していた小さなスタートアップ企業を買うの代わりに良好でした。残念ながら、小さなスタートアップ企業は、一般的に、任意の研究自体に資金を供給するために財政的に不可能です。
The result of reduced U.S. Government funding and profit-focused, low-risk, short-term industry funding has been a decline in higher-risk but more innovative research activities. Industry has also been less interested in research to evolve the overall Internet architecture, because such work does not translate into a competitive advantage for the firm funding such work.
減少し、米国政府の資金と利益に焦点を当てた、低リスクの結果は、短期的な業界の資金調達は、高リスクの減少が、より革新的な研究活動となっています。このような作業はしっかり資金ような作業のために競争上の優位性に変換されませんので、業界でも、全体的なインターネットアーキテクチャを進化させる研究にはあまり興味を持ってきました。
The IAB believes that it would be helpful for governments and other non-commercial sponsors to increase their funding of both basic research and applied research relating to the Internet, and to sustain these funding levels going forward.
IABは、政府や他の非商業スポンサーは、両方の基礎研究の資金調達を増やし、インターネットに関連する研究を応用し、今後これらの資金のレベルを維持するためにすることが役立つだろうと考えています。
This section primarily discusses some specific topics that the IAB believes merit additional research. Research, of course, includes not just devising a theory, algorithm, or mechanism to accomplish a goal, but also evaluating the general efficacy of the approach and then the benefits vs. the costs of deploying that algorithm or mechanism. Important cautionary notes about this discussion are given in the next sub-section. This particular set of topics is not intended to be comprehensive, but instead is intended to demonstrate the breadth of open Internet research questions.
このセクションでは、主に、IABは、メリット、追加の研究を信じているいくつかの特定のトピックについて説明します。研究は、もちろん、単に理論、アルゴリズム、または目標を達成するためのメカニズムを工夫するだけでなく、アプローチの一般的な有効性とそのアルゴリズムや仕組みを導入する費用対その後、便益を評価していないが含まれます。この議論についての重要な注意事項は次のサブセクションに記載されています。話題のこの特定のセットは、包括的であることを意図していないが、代わりにオープンなインターネットの研究課題の幅広さを実証することを意図しています。
Other discussions of problems of the Internet that merit further research include the following: [CIPB02,Claffy03a,Floyd,NSF03a,NSF03b].
[CIPB02、Claffy03a、フロイド、NSF03a、NSF03b]：さらなる研究に値するインターネットの問題の他の議論は以下のものが含まれます。
This document is NOT intended as a guide for public funding agencies as to exactly which projects or proposals should or should not be funded.
この文書は、プロジェクトや提案がまたは資金提供すべきではないはずです正確になどの公共資金提供機関のためのガイドとして意図されていません。
In particular, this document is NOT intended to be a comprehensive list of *all* of the research questions that are important to further the evolution of the Internet; that would be a daunting task, and would presuppose a wider and more intensive effort than we have undertaken in this document.
特に、この文書は、インターネットの発展を促進するために重要である研究課題の*すべて*の包括的リストであるように意図されていません。それは大変な作業になり、私たちは、この文書で行ってきたよりも広く、より集中的な努力を前提とします。
Similarly, this document is not intended to list the research questions that are judged to be only of peripheral importance, or to survey the current (global; governmental, commercial, and academic) avenues for funding for Internet research, or to make specific recommendations about which areas need additional funding. The purpose of the document is to persuade the reader that ongoing research is needed towards the continued evolution of the Internet infrastructure; the purpose is not to make binding pronouncements about which specific areas are and are not worthy of future funding.
（;政府、商用、および学術グローバル）インターネット調査のための資金調達のための道、または約具体的な提言を行うために同様に、この文書は、唯一、周辺重要であると判断された研究課題の一覧を表示する、または現在は調査するものではありませんその領域は、追加の資金を必要とします。ドキュメントの目的は、進行中の研究は、インターネットインフラストラクチャの継続的な発展に向けて必要とされている読者を説得することです。目的は、特定の領域があり、将来の資金調達の価値はありませんかについての結合宣告を作ることではありません。
For some research clearly relevant to the future evolution of the Internet, there are grand controversies between competing proposals or competing schools of thought; it is not the purpose of this document to take positions in these controversies, or to take positions on the nature of the solutions for areas needing further research.
インターネットの将来の発展に明確に関連したいくつかの研究のために、競合する提案や思考の競合の学校間の壮大な論争があります。それは、これらの論争でポジションを取るために、またはさらなる研究が必要な分野のためのソリューションの性質上の位置を取るために、このドキュメントの目的ではありません。
That all carefully noted, the remainder of this section discusses a broad set of research areas, noting a subset of particular topics of interest in each of those research areas. Again, this list is NOT comprehensive, but rather is intended to suggest that a broad range of ongoing research is needed, and to propose some candidate topics.
その全て慎重に留意、このセクションの残りの部分は、これらの研究領域の各々における関心のある特定のトピックのサブセットに注目、研究分野の広範なセットを論じています。ここでも、このリストは包括的ではなく、現在進行中の研究の幅広いが必要とされていることを示唆し、そしていくつかの候補のトピックを提案することを意図しています。
Several places in this document refer to 'network operators'. By that term, we intend to include anyone or any organization that operates an IP-based network; we are not using that term in the narrow meaning of commercial network service providers.
このドキュメントのいくつかの場所は、「ネットワークオペレーター」を参照してください。その用語によって、我々は誰か、IPベースのネットワークを運営するあらゆる組織を含めるつもり。我々は、商用ネットワークサービスプロバイダの狭い意味でその用語を使用していません。
The Internet currently has several different namespaces, including IP addresses, sockets (specified by the IP address, upper-layer protocol, and upper-layer port number), Autonomous System (AS) number, and the Fully-Qualified Domain Name (FQDN). Many of the Internet's namespaces are supported by the widely deployed Domain Name System [RFC-3467] or by various Internet applications [RFC-2407, Section 4.6.2.1]
インターネットは、現在のIPアドレスを含む、いくつかの異なる名前空間を有する、ソケット（IPアドレス、上位層プロトコル、および上層ポート番号で指定）、自律システム（AS）番号、および完全修飾ドメイン名（FQDN） 。インターネットの名前空間の多くは、広く導入されているドメインネームシステム[RFC-3467]によって、または様々なインターネットアプリケーションによってサポートされています[RFC-2407、セクション4.6.2.1]
The DNS system, while it works well given its current constraints, has several stress points.
DNSシステム、それが現在の制約を与えうまく機能している間は、いくつかの応力点を持っています。
The current DNS system relies on UDP for transport, rather than SCTP or TCP. Given the very large number of clients using a typical DNS server, it is desirable to minimize the state on the DNS server side of the connection. UDP does this well, so it is a reasonable choice, though this has other implications, for example a reliance on UDP fragmentation. With IPv6, intermediate fragmentation is not allowed and Path MTU Discovery is mandated. However, the amount of state required to deploy Path MTU Discovery for IPv6 on a DNS server might be a significant practical problem.
現在のDNSシステムではなく、SCTPまたはTCPよりも、輸送のためにUDPに依存しています。典型的なDNSサーバを使用しているクライアントの非常に大きな数を考えると、接続のDNSサーバ側の状態を最小にすることが望ましいです。 UDPはよくこれを行いますので、これは例えば、UDPフラグメンテーションへの依存を他の意味を持っているけれども、それは、合理的な選択です。 IPv6では、中間断片化は許可されていませんし、パスMTUディスカバリが義務付けられています。しかし、DNSサーバでIPv6のパスMTUディスカバリーを展開するために必要な状態の量は、重要な実用上の問題かもしれません。
One implication of this is that research into alternative transport protocols, designed more for DNS-like applications where there are very many clients using each server, might be useful. Of particular interest would be transport protocols with little burden for the DNS server, even if that increased the burden somewhat for the DNS client.
これの一の意味合いが各サーバを使用して非常に多くのクライアントが存在するDNSのようなアプリケーションのためのより多くの設計代替トランスポートプロトコル、にその研究で、役に立つかもしれません。特に興味深いのは、トランスポートプロトコルは、それがDNSクライアントのために多少の負担を増加させた場合でも、DNSサーバーのために少し負担となります。
Additional study of DNS caching, both currently available caching techniques and also of potential new caching techniques, might be helpful in finding ways to reduce the offered load for a typical DNS server. In particular, examination of DNS caching through typical commercial firewalls might be interesting if it lead to alternative firewall implementations that were less of an obstacle to DNS caching.
DNSキャッシュの追加の研究、潜在的な新しいキャッシュ技術のも、両方の現在利用可能なキャッシュ技術とは、一般的なDNSサーバ用に提供負荷を軽減する方法を見つけるのに役立つかもしれません。それはDNSキャッシュの障害の少なかった代わりのファイアウォールの実装につながる場合は特に、典型的な市販のファイアウォール経由でDNSキャッシングの審査は面白いかもしれません。
The community lacks a widely-agreed-upon set of metrics for measuring DNS server performance. It would be helpful if people would seriously consider what characteristics of the DNS system should be measured.
コミュニティは、広く合意されたメトリックのセットDNSサーバーのパフォーマンスを測定するために欠けています。人々は真剣に測定すべきかDNSシステムの特性検討する場合には参考になります。
Some in the community would advocate replacing the current DNS system with something better. Past attempts to devise a better approach have not yielded results that persuaded the community to change. Proposed work in this area could be very useful, but might require careful scrutiny to avoid falling into historic design pitfalls.
コミュニティのいくつかは、より良い何かを、現在のDNSシステムを置き換える提唱でしょう。より良いアプローチを考案する過去の試みは変更するコミュニティを説得した結果が得られていません。この分野での提案の仕事は非常に便利かもしれないが、歴史的なデザインの落とし穴に陥るのを避けるために慎重な精査が必要な場合があります。
With regards to DNS security, major technical concerns include finding practical methods for signing very large DNS zones (e.g., and tools to make it easier to manage secure DNS infrastructure.
DNSのセキュリティに関しては、主要な技術的な懸念は、それが簡単にセキュアなDNSインフラストラクチャを管理するために作ることは非常に大規模なDNSゾーン（例えば、およびツールに署名するための実用的な方法を見つけることがあります。
Most users are unable to distinguish a DNS-related failure from a more general network failure. Hence, maintaining the integrity and availability of the Domain Name System is very important for the future health of the Internet.
ほとんどのユーザーは、より一般的なネットワーク障害からのDNS関連の障害を区別することはできません。そのため、ドメインネームシステムの完全性、可用性を維持することは、インターネットの将来の健康のために非常に重要です。
Additionally, the Namespace Research Group (NSRG) of the Internet Research Task Force (IRTF) studied adding one or more additional namespaces to the Internet Architecture [LD2002]. Many members of the IRTF NSRG believe that there would be significant architectural benefit to adding one or more additional namespaces to the Internet Architecture. Because smooth consensus on that question or on the properties of a new namespace was not obtained, the IRTF NSRG did not make a formal recommendation to the IETF community regarding namespaces. The IAB believes that this is an open research question worth examining further.
また、インターネットリサーチタスクフォースの名前空間研究グループ（NSRG）（IRTF）は、インターネットアーキテクチャ[LD2002]に1つの以上の追加の名前空間を追加することについて検討しました。 IRTF NSRGの多くのメンバーは、インターネットアーキテクチャに1つの以上の追加の名前空間を追加するのに重要な建築利益があるだろうと信じています。その質問に、または新しい名前空間の性質上の円滑な合意が得られなかったので、IRTF NSRGは、名前空間に関するIETFコミュニティに正式な勧告をしませんでした。 IABは、これがさらに調べる価値が開い研究課題であると考えています。
Finally, we believe that future research into the evolution of Internet-based distributed computing might well benefit from studying adding additional namespaces as part of a new approach to distributed computing.
最後に、我々は、インターネットベースの分散コンピューティングの進化への今後の研究がうまく分散コンピューティングへの新しいアプローチの一環として、追加の名前空間を追加する勉強の恩恵を受ける可能性があると信じています。
The currently deployed unicast routing system works reasonably well for most users. However, the current unicast routing architecture is suboptimal in several areas, including the following: end-to-end convergence times in global-scale catenets (a system of networks interconnected via gateways); the ability of the existing inter-domain path-vector algorithm to scale well beyond 200K prefixes; the ability of both intra-domain and inter-domain routing to use multiple metrics and multiple kinds of metrics concurrently; and the ability of IPv4 and IPv6 to support widespread site multi-homing without undue adverse impact on the inter-domain routing system. Integrating policy into routing is also a general concern, both for intra-domain and inter-domain routing. In many cases, routing policy is directly tied to economic issues for the network operators, so applied research into routing ideally would consider economic considerations as well as technical considerations.
現在展開ユニキャストルーティングシステムは、ほとんどのユーザーのために合理的にうまく機能します。しかし、現在のユニキャストルーティングアーキテクチャは、以下を含むいくつかの分野で最適以下である：地球規模のcatenetsにおけるエンド・ツー・エンドの収束時間（ゲートウェイを介して相互接続されたネットワークのシステム）。 200Kプレフィックスをはるかに超えて拡張するために、既存のドメイン間のパスベクトルアルゴリズムの能力;同時に複数のメトリックおよびメトリックの複数種類を使用するドメイン内およびドメイン間ルーティングの両方の能力。そして、ドメイン間ルーティングシステムへの過度の有害な影響を与えることなく、広範囲のサイトマルチホーミングをサポートするため、IPv4とIPv6の能力。ルーティングにポリシーを統合すると、両方のドメイン内およびドメイン間ルーティングのために、また一般的な問題です。多くの場合、ルーティングポリシーが直接ので経済的考慮だけでなく、技術的な考慮事項を検討する理想的なルーティングに関する研究を適用し、ネットワーク事業者のための経済問題に結びついています。
This is an issue for which the commercial interest is clear, but that seems unlikely to be solved through commercial funding for research, in the absence of a consortium of some type.
これは、商業的関心がクリアされている問題であるが、それはいくつかのタイプのコンソーシアムが存在しない場合に、研究のための商業資金によって解決される可能性は低いようです。
The current operational inter-domain routing system has between 150,000 and 200,000 routing prefixes in the default-free zone (DFZ) [RFC-3221]. ASIC technology obviates concerns about the ability to forward packets at very high speeds. ASIC technology also obviates concerns about the time required to perform longest-prefix-match computations. However, some senior members of the Internet routing community have concerns that the end-to-end convergence properties of the global Internet might hit fundamental algorithmic limitations (i.e., not hardware limitations) when the DFZ is somewhere between 200,000 and 300,000 prefixes. Research into whether this concern is well-founded in scientific terms seems very timely.
現在の動作ドメイン間ルーティングシステムは、デフォルトフリーゾーン（DFZ）[RFC-3221] 150,000の間に200,000ルーティングプレフィックスを有しています。 ASIC技術は、非常に高速でパケットを転送する能力についての懸念を解消します。 ASIC技術は、最長プレフィックス合致計算を実行するのに必要な時間についての懸念を解消します。しかし、インターネットルーティングコミュニティの一部の幹部はDFZ 200,000〜300,000プレフィックスの間のどこかにあるときに、グローバルなインターネットのエンド・ツー・エンドの収束特性が基本的なアルゴリズムの制限（つまり、いないハードウェアの制限を）打つかもしれない懸念があります。この問題は、科学的な用語でよく設立されているかどうかの研究は非常にタイムリーなようです。
Separately from the above concern, recent work has shown that there can be significant BGP convergence issues today. At present, it appears that the currently observed convergence issues relate to how BGP has been configured by network operators, rather than being any sort of fundamental algorithmic limitation [MGVK02]. This convergence time issue makes the duration of the apparent network outage much longer than it should be. Additional applied research into which aspects of a BGP configuration have the strongest impact on convergence times would help mitigate the currently observed operational issues.
別に上記の懸念から、最近の研究では、今日の重要なBGPコンバージェンスの問題があることを示しています。現在のところ、現在観察収束の問題がなく基本的なアルゴリズムの制限[MGVK02]の任意の並べ替えであるよりも、BGPは、ネットワークオペレータによって設定されたかに関すると思われます。この収束時間の問題は、それがあるべきよりも見かけのネットワーク停止の期間がかなり長くなります。追加の応用研究は、その中にBGP設定の側面は、現在観測運用上の問題を軽減するのに役立つだろうコンバージェンス時間に最強のインパクトを持っています。
Also, inter-domain routing currently requires significant human engineering of specific inter-AS paths to ensure that reasonably optimal paths are used by actual traffic. Ideally, the inter-domain routing system would automatically cause reasonably optimal paths to be chosen. Recent work indicates that improved BGP policy mechanisms might help ensure that reasonably optimal paths are normally used for inter-domain IP traffic. [SMA03] Continued applied research in this area might lead to substantially better technical approaches.
また、ドメイン間ルーティングは、現在、その合理的に最適なパスは、実際のトラフィックによって使用されることを保証するために、特定のAS間の経路の重要な人間工学が必要です。理想的には、ドメイン間ルーティングシステムは自動的に合理的に最適な経路を選択させるであろう。最近の研究では、改善BGPポリシーメカニズムが合理的に最適なパスは、通常、ドメイン間のIPトラフィックに使用されていることを確認に役立つかもしれないことを示しています。 [SMA03]この領域での継続的な応用研究は、実質的に良好な技術的アプローチにつながる可能性があります。
The current approach to site multi-homing has the highly undesirable side-effect of significantly increasing the growth rate of prefix entries in the DFZ (by impairing the deployment of prefix aggregation). Research is needed into new routing architectures that can support large-scale site multi-homing without the undesirable impacts on inter-domain routing of the current multi-homing technique.
サイトマルチホーミングへの現在のアプローチは、有意に（プレフィックス集約の展開を損なうことによって）DFZにおける接頭エントリの成長速度を増大させる非常に望ましくない副作用を有します。研究は、現在のマルチホーミング技術のドメイン間ルーティングに好ましくない影響を与えることなく、大規模なサイトマルチホーミングをサポートできる新しいルーティング・アーキテクチャに必要とされています。
The original application for BGP was in inter-domain routing, primarily within service provider networks but also with some use by multi-homed sites. However, some are now trying to use BGP in other contexts, for example highly mobile environments, where it is less obviously well suited. Research into inter-domain routing and/or intra-domain policy routing might lead to other approaches for any emerging environments where the current BGP approach is not the optimal one.
BGPのための元のアプリケーションは、主に、サービスプロバイダーネットワーク内だけでなく、マルチホームのサイトによっていくつか使用して、ドメイン間ルーティングにありました。しかし、いくつかは、今ではあまり明らかに適していますたとえば、高度モバイル環境のために、他のコンテキストでBGPを使用しようとしています。ドメイン間ルーティングおよび/またはドメイン内のポリシールーティングの研究は、現在のBGPのアプローチが最適なものではありません任意の新興環境のための他のアプローチにつながる可能性があります。
Recently there has been increased awareness of the longstanding issue of deploying strong authentication into the Internet inter-domain routing system. Currently deployed mechanisms (e.g., BGP TCP MD5 [RFC-2385], OSPF MD5, RIP MD5 [RFC-2082]) provide cryptographic authentication of routing protocol messages, but no authentication of the actual routing data. Recent proposals (e.g., S-BGP [KLMS2000]) for improving this in inter-domain routing appear difficult to deploy across the Internet, in part because of their reliance on a single trust hierarchy (e.g., a single PKI). Similar proposals (e.g., OSPF with Digital Signatures, [RFC-2154]) for intra-domain routing are argued to be computationally infeasible to deploy in a large network.
最近、インターネットドメイン間ルーティングシステムに強力な認証を導入するの長年の問題への意識が高まってきました。現在展開機構（例えば、BGP TCP MD5 [RFC-2385]、OSPF MD5、RIP MD5 [RFC-2082]）を暗号ルーティングプロトコルメッセージの認証、実際のルーティング・データのない認証を提供します。ドメイン間ルーティングでこれを改善するための最近の提案（例えば、S-BGP [KLMS2000]）があるため、単一の信頼階層（例えば、単一のPKI）への依存の一部には、インターネットを介して配布することが困難と思われます。同様の提案は（例えば、デジタル署名、[RFC-2154]とOSPF）ドメイン内ルーティングのためには、大規模なネットワークで展開する計算上実行不可能であると主張されています。
A recurring challenge with any form of inter-domain routing authentication is that there is no single completely accurate source of truth about which organizations have the authority to advertise which address blocks. Alternative approaches to authentication of data in the routing system need to be developed. In particular, the ability to perform partial authentication of routing data would facilitate incremental deployment of routing authentication mechanisms. Also, the ability to use non-hierarchical trust models (e.g., the web of trust used in the PGP application) might facilitate incremental deployment and might resolve existing concerns about centralized administration of the routing system, hence it merits additional study and consideration.
ドメイン間ルーティング認証のいずれかの形式での定期的な課題は、組織がアドレスブロックを宣伝する権限を持っているかについての真実の単一完全に正確なソースがないことです。ルーティングシステムにおけるデータの認証に別のアプローチを開発する必要があります。具体的には、ルーティング・データの部分認証を実行する能力は、認証メカニズムをルーティングする増分展開を容易にするであろう。また、非階層信頼モデルを使用する機能（例えば、PGPアプリケーションで使用される信頼のウェブ）は、それゆえにメリット追加の調査と検討を増分展開を容易かもしれないし、ルーティングシステムの集中管理に関する既存の懸念を解決することがあります。
The current Internet routing system relies primarily on two algorithms. Link-state routing uses the Dijkstra algorithm [Dijkstra59]. Distance-Vector routing (e.g., RIP) and Path-Vector routing (e.g., BGP) use the Bellman-Ford algorithm [Bellman1957, FF1962]. Additional ongoing basic research into graph theory as applied to routing is worthwhile and might yield algorithms that would enable a new routing architecture or otherwise provide improvements to the routing system.
現在のインターネットルーティングシステムは、2つのアルゴリズムに主に依存しています。リンク状態ルーティングは[Dijkstra59]ダイクストラのアルゴリズムを使用します。距離ベクトルルーティング（例えば、RIP）およびパスベクトルルーティング（例えば、BGP）は、ベルマン - フォード法[Bellman1957、FF1962]を使用します。ルーティングに適用されるように、グラフ理論への追加の継続的な基礎研究は価値があり、新たなルーティングアーキテクチャを有効にするか、そうでない場合は、ルーティングシステムの改善を提供するアルゴリズムをもたらすかもしれません。
Currently deployed multicast routing relies on the Deering RPF algorithm [Deering1988]. Ongoing research into alternative multicast routing algorithms and protocols might help alleviate current concerns with the scalability of multicast routing.
現在展開マルチキャストルーティングは、[Deering1988]デアリングRPFアルゴリズムに依存しています。代替マルチキャストルーティングアルゴリズムとプロトコルへの継続的な研究は、マルチキャストルーティングのスケーラビリティを持つ現在の懸念を軽減することがあります。
The deployed Internet routing system assumes that the shortest path is always the best path. This is provably false, however it is a reasonable compromise given the routing protocols currently available. The Internet lacks deployable approaches for policy-based routing or routing with alternative metrics (i.e., some metric other than the number of hops to the destination). Examples of alternative policies include: the path with lowest monetary cost; the path with the lowest probability of packet loss; the path with minimized jitter; and the path with minimized latency. Policy metrics also need to take business relationships into account. Historic work on QoS-based routing has tended to be unsuccessful in part because it did not adequately consider economic and commercial considerations of the routing system and in part because of inadequate consideration of security implications.
展開インターネットルーティングシステムは、最短パスが常に最善の道であることを前提としています。これは、しかし、それは、ルーティングプロトコル、現在入手可能な一定の合理的な妥協である、証明可能falseです。インターネットは別のメトリック（宛先までのホップ数よりも、すなわち、いくつかのメトリック他）と、ポリシーベースのルーティングまたはルーティングのための展開アプローチを欠いています。代替政策の例としては、最低の金銭的コストのパスを、パケット損失の最も低い確率を有する経路;最小ジッタ経路;そして最小限の待ち時間でパス。政策評価指標も考慮にビジネス関係を取る必要があります。 QoSベースのルーティングの歴史的な作品は、それが十分にあるため、セキュリティに影響の不十分な対価の一部ルーティングシステムのとの経済・商業の考慮事項を考慮していなかったので、一部で失敗する傾向にありました。
Transitioning from the current inter-domain routing system to any new inter-domain routing system is unlikely to be a trivial exercise. So any proposal for a new routing system needs to carefully consider and document deployment strategies, transition mechanisms, and other operational considerations. Because of the cross-domain interoperability aspect of inter-domain routing, smooth transitions from one inter-domain routing system are likely to be difficult to accomplish. Separately, the inter-domain routing system lacks strong market forces that would encourage migration to better technical approaches. Hence, it appears unlikely that the commercial sector will be the source of a significantly improved inter-domain routing system.
新たなドメイン間ルーティングシステムに現在のドメイン間ルーティングシステムからの移行は些細な運動になることはほとんどありません。だから、新しいルーティングシステムのための任意の提案は、慎重に検討し、文書配布の戦略、移行メカニズム、および他の動作配慮する必要があります。なぜならドメイン間ルーティングのクロスドメインの相互運用性の観点から、1ドメイン間ルーティングシステムからのスムーズな移行を達成することは困難である可能性があります。これとは別に、ドメイン間ルーティングシステムは、より良い技術的なアプローチへの移行を促すだろう、強力な市場の力を欠いています。したがって、商業部門が大幅に改善ドメイン間ルーティングシステムの源になるとは考えにくい表示されます。
While some of the earliest DARPA-sponsored networking research involved packet radio networks, mobile routing [IM1993] and mobile ad-hoc routing [RFC-2501] are relatively recent arrivals in the Internet, and are not yet widely deployed. The current approaches are not the last word in either of those arenas. We believe that additional research into routing support for mobile hosts and mobile networks is needed. Additional research for ad-hoc mobile hosts and mobile networks is also worthwhile. Ideally, mobile routing and mobile ad-hoc routing capabilities should be native inherent capabilities of the Internet routing architecture. This probably will require a significant evolution from the existing Internet routing architecture. (NB: The term "mobility" as used here is not limited to mobile telephones, but instead is very broadly defined, including laptops that people carry, cars/trains/aircraft, and so forth.)
パケット無線ネットワークを関与早いDARPA主催のネットワーキング研究のいくつかが、[IM1993]ルーティングし、モバイルアドホックルーティング[RFC-2501]モバイルはインターネットで比較的最近到着しており、まだ広く展開されていません。現在のアプローチは、これらのアリーナのどちらかの最後の言葉はありません。私たちは、モバイルホストとモバイルネットワークのためのルーティングのサポートに追加調査が必要であると信じています。アドホックモバイルホストとモバイルネットワークのための追加的な研究にも価値があります。理想的には、モバイルルーティングおよびモバイルアドホックルーティング機能は、インターネットルーティングアーキテクチャのネイティブ本来の機能である必要があります。これはおそらく、既存のインターネットルーティングアーキテクチャから大幅な進化が必要になります。 （NB：ここで使用される用語「モビリティ」は、携帯電話に限定されるものではなく、代わりに非常に広くなど、人々が運ぶのラップトップ、自動車/電車/飛行機などを含め、定義されています。）
Included in this topic are a wide variety of issues. The more distributed and dynamic nature of partially or completely self-organizing routing systems (including the associated end nodes) creates unique security challenges (especially relating to Authorization, Authentication, and Accounting, and relating to key management). Scalability of wireless networks can be difficult to measure or to achieve. Enforced hierarchy is one approach, but can be very limiting. Alternative, less constraining approaches to wireless scalability are desired. Because wireless link-layer protocols usually have some knowledge of current link characteristics such as link quality, sublayer congestion conditions, or transient channel behavior, it is desirable to find ways to let network-layer routing use such data. This raises architectural questions of what the proper layering should be, which functions should be in which layer, and also practical considerations of how and when such information sharing should occur in real implementations.
このトピックに含まれる問題の多種多様です。 （関連エンドノードを含む）部分的にまたは完全に自己組織ルーティングシステムのより分散及び動的な性質（特に認可、認証、およびアカウンティングに関連し、鍵管理に関する）固有のセキュリティの課題を作成します。ワイヤレスネットワークのスケーラビリティを測定するか、達成することが困難な場合があります。強制階層は一つの方法ですが、非常に制限することができます。無線スケーラビリティの代わりに、より少ない制約の手法が望まれています。無線リンク層プロトコルは、通常、リンク品質、サブレイヤの混雑状況、または一時チャネル動作と現在のリンク特性のいくつかの知識を持っているので、ネットワーク層のルーティングを使用、このようなデータを聞かせする方法を見つけることが望ましいです。これは、適切なレイヤーが関数がどの層であるべきである、こと、また、そのような情報の共有は、実際の実装で行われるべき方法と時期の実際的な考慮すべきかのアーキテクチャの問題を提起します。
The Internet has a reputation for not having sufficient security. In fact, the Internet has a number of security mechanisms standardized, some of which are widely deployed. However, there are a number of open research questions relating to Internet security. In particular, security mechanisms need to be incrementally deployable and easy to use. "[Security] technology must be easy to use, or it will not be configured correctly. If mis-configured, security will be lost, but things will `work'" [Schiller03].
インターネットは、十分なセキュリティを持っていないとの評判を持っています。実際には、インターネットが広く展開されているそのうちのいくつかは標準化されたセキュリティ・メカニズムの数を持っています。しかし、インターネットセキュリティに関するオープンな研究の質問がいくつかあります。具体的には、セキュリティ・メカニズムは、漸進的に展開し、使いやすいようにする必要があります。 [Schiller03]「[セキュリティ]の技術を使用するのは簡単でなければならない、またはそれが正しく設定されません。誤って設定した場合、セキュリティが失われますが、物事は `仕事"意志」。
There is an ongoing need for funding of basic research relating to Internet security, including funding of formal methods research that relates to security algorithms, protocols, and systems.
セキュリティ・アルゴリズム、プロトコル、およびシステムに関する正式な方法の研究の資金提供を含むインターネットセキュリティに関する基礎研究の資金調達のための継続的なニーズがあります。
For example, it would be beneficial to have more formal study of non-hierarchical trust models (e.g., PGP's Web-of-Trust model). Use of a hierarchical trust model can create significant limitations in how one might approach securing components of the Internet, for example the inter-domain routing system. So research to develop new trust models suited for the Internet or on the applicability of existing non-hierarchical trust models to existing Internet problems would be worthwhile.
例えば、非階層信頼モデル（例えば、PGPのWeb-のトラストモデル）のより正式な調査を持っていることが有益であろう。階層的な信頼モデルの使用は1つが、たとえば、ドメイン間ルーティングシステムをインターネットのコンポーネントを確保するアプローチかもしれない方法に重大な制限を作成することができます。だから、インターネットまたは既存のインターネット問題への既存の非階層信頼モデルの適用に適し新しい信頼モデルを開発するための研究は価値があるだろう。
While there has been some work on the application of formal methods to cryptographic algorithms and cryptographic protocols, existing techniques for formal evaluation of algorithms and protocols lack sufficient automation. This lack of automation means that many protocols aren't formally evaluated in a timely manner. This is problematic for the Internet because formal evaluation has often uncovered serious anomalies in cryptographic protocols. The creation of automated tools for applying formal methods to cryptographic algorithms and/or protocols would be very helpful.
暗号化アルゴリズムと暗号化プロトコル、アルゴリズムとプロトコルの正式な評価のための既存の技術への形式手法の適用に関するいくつかの作業が行われているが、十分な自動化を欠いています。自動化の欠如は、多くのプロトコルが正式にタイムリーに評価されていないことを意味します。正式な評価は、多くの場合、暗号化プロトコルに重大な異常を発見したので、これは、インターネットのための問題があります。暗号化アルゴリズムおよび/またはプロトコルに形式手法を適用するための自動化ツールの作成は非常に参考になります。
A recurring challenge to the Internet community is how to design, implement, and deploy key management appropriate to the myriad of security contexts existing in the global Internet. Most current work in unicast key management has focused on hierarchical trust models, because much of the existing work has been driven by corporate or military "top-down" operating models.
インターネットコミュニティへの定期的な挑戦は、設計、実装、およびグローバルなインターネットの既存のセキュリティコンテキストの無数の鍵管理、適切なを展開する方法です。既存の作業の多くは、企業や軍の「トップダウン」の動作モデルによって駆動されているため、ユニキャスト鍵管理のほとんどの現在の仕事は、階層的な信頼モデルに焦点を当てています。
The paucity of key management methods applicable to non-hierarchical trust models (see above) is a significant constraint on the approaches that might be taken to secure components of the Internet.
非階層信頼モデルに該当するキー管理方法の不足は、（上記参照）は、インターネットのコンポーネントを確保するために取られるかもしれないアプローチに重大な制約です。
Research focused on removing those constraints by developing practical key management methods applicable to non-hierarchical trust models would be very helpful.
研究は非常に参考になる非階層信頼モデルに適用できる実用的な鍵管理方法を開発することによって、これらの制約を取り除くことに焦点を当てました。
Topics worthy of additional research include key management techniques, such as non-hierarchical key management architectures (e.g., to support non-hierarchical trust models; see above), that are useful by ad-hoc groups in mobile networks and/or distributed computing.
アドホック・モバイルネットワーク内のグループ及び/又は分散コンピューティングによって有用である、追加の研究の価値があるトピックは、非階層的鍵管理アーキテクチャとして鍵管理技術を、（上記参照例えば、非階層信頼モデルをサポートするため）が挙げられます。
Although some progress has been made in recent years, scalable multicast key management is far from being a solved problem. Existing approaches to scalable multicast key management add significant constraints on the problem scope in order to come up with a deployable technical solution. Having a more general approach to scalable multicast key management (i.e., one having broader applicability and fewer constraints) would enhance the Internet's capabilities.
いくつかの進歩は近年行われているが、スケーラブルマルチキャストキー管理は解決される問題には程遠いです。スケーラブルマルチキャストキー管理するために、既存のアプローチは、展開の技術的な解決策を考え出すために、問題の範囲に大きな制約を追加します。スケーラブルマルチキャストキー管理（すなわち、1がより広範な適用性と少ない制約を持つ）のためのより一般的なアプローチを持つことは、インターネットの能力を高めるであろう。
In many cases, attribute negotiation is an important capability of a key management protocol. Experience with the Internet Key Exchange (IKE) to date has been that it is unduly complex. Much of IKE's complexity derives from its very general attribute negotiation capabilities. A new key management approach that supported significant attribute negotiation without creating challenging levels of deployment and operations complexity would be helpful.
多くの場合、属性の交渉は、鍵管理プロトコルの重要な機能です。これまでのインターネット鍵交換（IKE）の経験は、それが過度に複雑であることとなっています。 IKEの複雑さの多くは、その非常に一般的な属性の交渉能力に由来します。導入と運用の複雑さのレベルに挑戦を作成することなく、重要な属性のネゴシエーションをサポートする新しい鍵管理アプローチが参考になります。
There is an ongoing need to continue the open-world research funding into both cryptography and cryptanalysis. Most governments focus their cryptographic research in the military-sector. While this is understandable, those efforts often have limited (or no) publications in the open literature. Since the Internet engineering community must work from the open literature, it is important that open-world research continues in the future.
暗号化と解読の両方にオープン世界の研究資金を継続する継続的な必要性があります。ほとんどの政府は、軍事部門での暗号研究の焦点を合わせます。これは理解できるが、これらの努力は、多くの場合、公開された文献に（あるいは全く）出版物が限られています。インターネットエンジニアリングコミュニティがオープン文献から働かなければならないので、オープン世界の研究は、将来的に継続することが重要です。
MIT's Project Athena was an important and broadly successful research project into distributed computing. Project Athena developed the Kerberos [RFC-1510] security system, which has significant deployment today in campus environments. However, inter-realm Kerberos is neither as widely deployed nor perceived as widely successful as single-realm Kerberos. The need for scalable inter-domain user authentication is increasingly acute as ad-hoc computing and mobile computing become more widely deployed. Thus, work on scalable mechanisms for mobile, ad-hoc, and non-hierarchical inter-domain authentication would be very helpful.
MITのAthenaプロジェクトは、分散コンピューティングへの重要かつ広範に成功した研究プロジェクトでした。 Athenaプロジェクトは、キャンパス環境で、今日の重要な展開があるのKerberos [RFC-1510]セキュリティシステムを開発しました。しかし、レルム間Kerberosはどちらとして広く展開も単一レルムのKerberosとして広く成功したとして知覚されます。アドホックコンピューティングとモバイルコンピューティングをより広く展開になるようにスケーラブルなドメイン間のユーザー認証の必要性はますます深刻です。したがって、モバイル、アドホックのためのスケーラブルなメカニズムの作業、および非階層ドメイン間の認証は非常に参考になります。
Lots of work has been done on theoretically perfect security that is impossible to deploy. Unfortunately, the S-BGP proposal is an example of a good research product that has significant unresolved deployment challenges. It is far from obvious how one could widely deploy S-BGP without previously deploying a large-scale inter-domain public-key infrastructure and also centralizing route advertisement policy enforcement in the Routing Information Registries or some similar body. Historically, public-key infrastructures have been either very difficult or impossible to deploy at large scale. Security mechanisms that need additional infrastructure have not been deployed well. We desperately need security that is general, easy to install, and easy to manage.
作品の多くは、展開することは不可能である理論的に完全なセキュリティに行われています。残念ながら、S-BGPの提案は重要な未解決の展開の課題を持っている優れた研究製品の一例です。それは1つが広く、以前に大規模なドメイン間の公開鍵インフラストラクチャを導入しても、ルーティング情報レジストリまたはいくつかの類似の体内での経路広告ポリシーの施行を集中することなく、S-BGPを展開できどこまで明らかからです。歴史的に、公開鍵インフラストラクチャは、大規模に展開するかが非常に困難または不可能でした。追加のインフラストラクチャを必要とするセキュリティ・メカニズムは十分に展開されていません。私たちは必死に、一般的なインストールが簡単、および管理が容易でセキュリティを必要としています。
Historically, the Internet community has mostly ignored pure Denial of Service (DoS) attacks. This was appropriate at one time since such attacks were rare and are hard to defend against. However, one of the recent trends in adversarial software (e.g., viruses, worms) has been the incorporation of features that turn the infected host into a "zombie". Such zombies can be remotely controlled to mount a distributed denial of service attack on some victim machine. In many cases, the authorized operators of systems are not aware that some or all of their systems have become zombies. It appears that the presence of non-trivial numbers of zombies in the global Internet is now endemic, which makes distributed denial of service attacks a much larger concern. So Internet threat models need to assume the presence of such zombies in significant numbers. This makes the design of protocols resilient in the presence of distributed denial of service attacks very important to the health of the Internet. Some work has been done on this front [Savage00], [MBFIPS01], but more is needed.
歴史的に、インターネットコミュニティは、ほとんど純粋なサービス拒否（DoS）攻撃を無視しています。このような攻撃はまれであり、身を守るのは難しいですので、これは一度に適切でした。しかし、敵対ソフトウェアの最近のトレンドの一つは、（例えば、ウイルス、ワーム）「ゾンビ」に感染したホストを回す機能を組み込むとなっています。このようなゾンビは、リモートでいくつかのターゲットマシン上のサービス攻撃の分散拒否をマウントするように制御することができます。多くの場合、システムの認可事業者は、自社のシステムの一部またはすべてがゾンビになっていることに気づいていません。分散サービス拒否がはるかに大きい関心を攻撃せた、グローバルなインターネットでのゾンビの非自明な数字の存在は、今流行していることが表示されます。だから、インターネットの脅威モデルは、かなりの数で、このようなゾンビの存在を前提とする必要があります。これは、インターネットの健康に非常に重要なサービス攻撃の分散拒否の存在下で弾力性のプロトコルの設計を行います。いくつかの作品は、[MBFIPS01]、[Savage00]この前に行われているが、それ以上は必要とされています。
The Internet had early success in network device monitoring with the Simple Network Management Protocol (SNMP) and its associated Management Information Base (MIB). There has been comparatively less success in managing networks, in contrast to the monitoring of individual devices. Furthermore, there are a number of operator requirements not well supported by the current Internet management framework. It is desirable to enhance the current Internet network management architecture to more fully support operational needs.
インターネットは、簡易ネットワーク管理プロトコル（SNMP）とその関連管理情報ベース（MIB）とネットワーク機器の監視の初期の成功を収めました。個々のデバイスの監視とは対照的に、ネットワークの管理が比較的少ないの成功がありました。また、井戸現在のインターネット管理フレームワークによってサポートされていないオペレータの要求の数があります。より完全に運用上のニーズをサポートするために、現在のインターネットのネットワーク管理アーキテクチャを強化することが望ましいです。
Unfortunately, network management research has historically been very underfunded. Operators have complained that existing solutions are inadequate. Research is needed to find better solutions.
残念ながら、ネットワーク管理研究は、歴史的に非常に資金不足となっています。オペレータは、既存のソリューションが不十分であることを訴えています。研究は、よりよい解決策を見つけるために必要とされています。
At present there are few or no good tools for managing a whole network instead of isolated devices. For example, the lack of appropriate network management tools has been cited as one of the major barriers to the widespread deployment of IP multicast [Diot00,
現時点では、いくつかまたは代わりに分離されたデバイスのネットワーク全体を管理するための優れたツールがあります。例えば、適切なネットワーク管理ツールの欠如は、IPマルチキャスト[Diot00の広範な展開に主要な障壁の一つとして引用されています、
SM03]. Current network management protocols, such as the Simple Network Management Protocol (SNMP), are fine for reading status of well-defined objects from individual boxes. Managing networks instead of isolated devices requires the ability to view the network as a large distributed system. Research is needed on scalable distributed data aggregation mechanisms, scalable distributed event correlation mechanisms, and distributed and dependable control mechanisms.
SM03]。そのような簡易ネットワーク管理プロトコル（SNMP）などの現在のネットワーク管理プロトコルは、個々の箱から明確に定義されたオブジェクトの状態を読み取るための罰金です。代わりに、単離されたデバイスのネットワークを管理する大規模な分散システムのようなネットワークを表示する機能を必要とします。研究は、スケーラブルな分散データ集約メカニズム、スケーラブルな分散型イベント相関メカニズム、および分散と信頼性の制御機構に必要とされています。
Applied research into methods of managing sets of networked devices seems worthwhile. Ideally, such a management approach would support distributed management, rather than being strictly centralized.
ネットワーク接続されたデバイスのセットを管理する方法への応用研究が価値があると思われます。理想的には、このような管理アプローチはかなり厳しく、集中さよりも、分散管理をサポートしています。
SNMP does not always scale well to monitoring large numbers of objects in many devices in different parts of the network. An alternative approach worth exploring is how to provide scalable and distributed monitoring, not on individual devices, but instead on groups of devices and the network-as-a-whole. This requires scalable techniques for data aggregation and event correlation of network status data originating from numerous locations in the network.
SNMPは、常にネットワークのさまざまな部分で多くのデバイスに多数のオブジェクトを監視するだけでなく拡張できません。探検する価値別のアプローチではなく、個々のデバイス上で、代わりにデバイスのグループやネットワークなど-全体的にスケーラブルな分散監視を提供する方法です。これは、ネットワーク内の多くの場所から発信されるネットワーク・ステータス・データのデータ集約およびイベント相関のためのスケーラブルな技術が必要となります。
An open issue related to network management is helping users and others to identify and resolve problems in the network. If a user can't access a web page, it would be useful if the user could find out, easily, without having to run ping and traceroute, whether the problem was that the web server was down, that the network was partitioned due to a link failure, that there was heavy congestion along the path, that the DNS name couldn't be resolved, that the firewall prohibited the access, or that some other specific event occurred.
ネットワーク管理に関する未解決の問題は、ネットワークの問題を特定し、解決するために、ユーザーや他の人を支援しています。ユーザーがWebページにアクセスすることができない場合、ユーザはネットワークがのために分配したという、問題はウェブサーバがダウンしたことがあったかどうか、pingやtracerouteを実行することなく、簡単に、見つけることができれば、それは有用であろうリンク障害、DNS名は、ファイアウォールがアクセスを禁止していること、または他のいくつかの特定のイベントが発生したことを、解決できなかったことをパスに沿って重い輻輳が、あったこと。
More research is needed to improve the degree of automation achieved by network management systems and to localize management. Autonomous network management might involve the application of control theory, artificial intelligence or expert system technologies to network management problems.
より多くの研究は、ネットワーク管理システムによって達成自動化の度合いを向上させ、管理をローカライズするために必要とされます。自律ネットワーク管理は、管理上の問題をネットワークするための制御理論、人工知能やエキスパートシステム技術の適用を必要とするかもしれません。
There has been an intensive body of research and development work on adding QoS to the Internet architecture for more than ten years now [RFC-1633, RFC-2474, RFC-3260, RFC-2205, RFC-2210], yet we still
我々はまだ[RFC-1633、RFC-2474、RFC-3260、RFC-2205、RFC-2210]今、10年以上のインターネットアーキテクチャにQoSを追加することで、研究開発の仕事の集中的なボディとなって、まだいます
don't have end-to-end QoS in the Internet [RFC-2990, RFC-3387]. The IETF is good at defining individual QoS mechanisms, but poor at work on deployable QoS architectures. Thus, while Differentiated Services (DiffServ) mechanisms have been standardized as per-hop behaviors, there is still much to be learned about the deployment of that or other QoS mechanisms for end-to-end QoS. In addition to work on purely technical issues, this includes close attention to the economic models and deployment strategies that would enable an increased deployment of QoS in the network.
インターネットでのエンドツーエンドのQoS [RFC-2990、RFC-3387]を持っていません。 IETFは、個々のQoSメカニズムを定義するのが得意ですが、展開可能なQoSアーキテクチャ上の仕事で貧しいです。差別化サービス（DiffServの）メカニズムは、ホップごとの挙動として標準化されていながら、このように、その展開やエンド・ツー・エンドのQoSのための他のQoSメカニズムについて学んだことが多くがまだあります。純粋に技術的な問題を上の仕事に加えて、これは、ネットワーク内のQoSの増加の展開を可能にする経済モデルと展開戦略に細心の注意を含んでいます。
In many cases, deployment of QoS mechanisms would significantly increase operational security risks [RFC-2990], so any new research on QoS mechanisms or architectures ought to specifically discuss the potential security issues associated with the new proposal(s) and how to mitigate those security issues.
多くの場合、QoSメカニズムの展開が大幅に運用上のセキュリティリスク[RFC-2990]を増加することになるので、QoSメカニズムやアーキテクチャ上の任意の新しい研究は、特に新たな提案（複数可）に関連する潜在的なセキュリティ問題を議論するべきだとどのようにそれらを軽減するためにセキュリティ上の問題。
In some cases, the demand for QoS mechanisms has been diminished by the development of more resilient voice/video coding techniques that are better suited for the best-effort Internet than the older coding techniques that were originally designed for circuit-switched networks.
いくつかのケースでは、QoSメカニズムの需要は当初、回線交換ネットワーク向けに設計されていた古いコーディング技術よりもベストエフォート型のインターネットに適しているより弾力性の音声/ビデオ符号化技術の開発によって減少されています。
One of the factors that has blunted the demand for QoS has been the transition of the Internet infrastructure from heavy congestion in the early 1990s, to overprovisioning in backbones and in many international links now. Thus, research in QoS mechanisms also has to include some careful attention to the relative costs and benefits of QoS in different places in the network. Applied research into QoS should include explicit consideration of economic issues of deploying and operating a QoS-enabled IP network [Clark02].
QoSの需要を鈍らせた要因の一つは、今バックボーンにし、多くの国際リンクにオーバープロビジョニングするために、1990年代初頭に混雑からのインターネットインフラの推移となっています。このように、QoSメカニズムの研究はまた、ネットワーク内の別の場所でのQoSの相対的なコストと利益にいくつかの注意を含まなければなりません。 QoSのへの応用研究は、QoS対応のIPネットワーク[Clark02]を展開し、操作するの経済問題を明示的に考慮を含むべきです。
Typically, a router in the deployed inter-domain Internet provides best-effort forwarding of IP packets, without regard for whether the source or destination of the packet is a direct customer of the operator of the router. This property is a significant contributor to the current scalability of the global Internet and contributes to the difficulty of deploying inter-domain Quality of Service (QoS) mechanisms.
一般的に、展開ドメイン間のインターネットにおけるルータは、パケットの送信元や宛先がルータのオペレータの直接の顧客であるかどうかに関係なく、IPパケットのベストエフォート型の転送を提供します。このプロパティは、グローバルなインターネットの現在のスケーラビリティに多大な貢献であるとService（QoS）のメカニズムのドメイン間の品質を展開することの難しさに貢献しています。
Deploying existing Quality-of-Service (QoS) mechanisms, for example Differentiated Services or Integrated Services, across an inter-domain boundary creates a significant and easily exploited denial-of-service vulnerability for any network that provides inter-domain QoS support. This has caused network operators to refrain from supporting inter-domain QoS. The Internet would benefit from additional research into alternative approaches to QoS, particularly into approaches that do not create such vulnerabilities and can be deployed end-to-end [RFC-2990].
ドメイン間の境界を越えて、例えば、差別化サービスや統合サービスのために、既存のサービス品質（QoS）のメカニズムを展開すると、ドメイン間のQoSサポートを提供する任意のネットワークのための重要かつ簡単に悪用サービス拒否の脆弱性を作成します。これは、ネットワーク事業者は、ドメイン間のQoSをサポートする控えるように起こしています。インターネットは、特にそのような脆弱性を作成しないと、エンドツーエンドの[RFC-2990]展開できるアプローチに、QoSのへの代替アプローチへの追加的な研究の恩恵を受けるだろう。
Also, current business models are not consistent with inter-domain QoS, in large part because it is impractical or impossible to authenticate the identity of the sender of would-be preferred traffic while still forwarding traffic at line-rate. Absent such an ability, it is unclear how a network operator could bill or otherwise recover costs associated with providing that preferred service. So any new work on inter-domain QoS mechanisms and architectures needs to carefully consider the economic and security implications of such proposals.
また、現在のビジネスモデルは、まだラインレートでトラフィックを転送しながら-だろう優先トラフィックの送信者の身元を認証するために、非現実的または不可能である大部分であるため、ドメイン間のQoSと一致していません。こうした能力不在、ネットワークオペレータが課金あるいはその優先サービスの提供に関連するコストを回収できるかは不明です。だから、ドメイン間のQoSメカニズムとアーキテクチャ上の任意の新しい仕事は慎重にそのような提案の経済と安全保障の影響を考慮する必要があります。
The overall Quality-of-Service for traffic is in part determined by the scheduling and queue management mechanisms at the routers. While there are a number of existing mechanisms (e.g., RED) that work well, it is possible that improved active queuing strategies might be devised. Mechanisms that lowered the implementation cost in IP routers might help increase deployment of active queue management, for example.
全体的なサービス品質（QoS）トラフィックのためには、ルータでのスケジューリングとキュー管理メカニズムによって決まる部分です。うまく機能既存のメカニズム（例えば、RED）の数があるが、アクティブキューイング戦略が考案される可能性が改善されることが可能です。例えば、アクティブキュー管理の展開を高めるのを助けるかもしれないIPルータの実装コストを下げるメカニズム。
TCP's congestion avoidance and control mechanisms, from 1988 [Jacobson88], have been a key factor in maintaining the stability of the Internet, and are used by the bulk of the Internet's traffic. However, the congestion control mechanisms of the Internet need to be expanded and modified to meet a wide range of new requirements, from new applications such as streaming media and multicast to new environments such as wireless networks or very high bandwidth paths, and new requirements for minimizing queueing delay. While there are significant bodies of work in several of these issues, considerably more needs to be done.
TCPの輻輳回避および制御メカニズムは、1988 [Jacobson88]から、インターネットの安定性を維持する上で重要な要因となっている、とインターネットのトラフィックの大部分で使用されています。しかし、インターネットの輻輳制御メカニズムは、例えば、無線ネットワークまたは非常に高帯域幅パスとして新しい環境にメディア及びマルチキャストストリーミングなどの新しいアプリケーションから、新しい要件の広い範囲を満たすように拡張、変更する必要がある、とのための新しい要件キューイング遅延を最小限に抑えます。仕事の重要な機関がこれらの問題のいくつかにありますが、かなり多く行う必要があります。
We would note that research on TCP congestion control is also not yet "done", with much still to be accomplished in high-speed TCP, or in adding robust performance over paths with significant reordering, intermittent connectivity, non-congestive packet loss, and the like.
我々はまだ多くが、または重大な並べ替え、断続的な接続、非うっ血パケット損失の経路を介して堅牢なパフォーマンスを追加することで、高速TCPで達成することで、TCPの輻輳制御上の研究もまだ「完了」ではないことに注意して、そしてだろう以下のように。
Several of these issues bring up difficult fundamental questions about the potential costs and benefits of increased communication between layers. Would it help transport to receive hints or other information from routing, from link layers, or from other transport-level connections? If so, what would be the cost to robust operation across diverse environments?
これらの問題のいくつかは、層間の増加通信の潜在的なコストと便益に関する困難な基本的な質問を持ち出します。それは、リンク層からの、または他のトランスポートレベルの接続から、ルーティングからのヒントや他の情報を受け取るために輸送を助けるだろうか？もしそうなら、何が多様な環境全体堅牢な動作にコストでしょうか？
For congestion control mechanisms in routers, active queue management and Explicit Congestion Notification are generally not yet deployed, and there are a range of proposals, in various states of maturity, in this area. At the same time, there is a great deal that we still do not understand about the interactions of queue management mechanisms with other factors in the network. Router-based congestion control mechanisms are also needed for detecting and responding to aggregate congestion such as in Distributed Denial of Service attacks and flash crowds.
ルータにおける輻輳制御メカニズムのため、アクティブキュー管理と明示的輻輳通知は、一般にまだ展開されていない、と提案の範囲は、この領域では、成熟の様々な状態で存在します。同時に、我々はまだ、ネットワーク内の他の要因とキュー管理メカニズムの相互作用について理解していない非常に多くあります。ルータベースの輻輳制御メカニズムも検出し、そのようなサービスの攻撃やフラッシュ群衆の分散型DoS攻撃のような混雑を集約するために応答するために必要とされます。
As more applications have the need to transfer very large files over high delay-bandwidth-product paths, the stresses on current congestion control mechanisms raise the question of whether we need more fine-grained feedback from routers. This includes the challenge of allowing connections to avoid the delays of slow-start, and to rapidly make use of newly-available bandwidth. On a more general level, we don't understand the potential and limitations for best-effort traffic over high delay-bandwidth-product paths, given the current feedback from routers, or the range of possibilities for more explicit feedback from routers.
より多くのアプリケーションは、高遅延帯域幅積のパス上で非常に大きなファイルを転送する必要性を持っているとして、現在の輻輳制御機構にかかる応力は、我々は、ルータからのよりきめ細かいフィードバックが必要かどうかの問題を提起します。これは、接続がスロースタートの遅延を回避するために、急速に新たに利用可能な帯域幅を利用するためにできるようにするという課題を含んでいます。より一般的なレベルでは、我々は、ルータからの電流フィードバック、またはルータからのより明示的なフィードバックのための可能性の範囲を与え、高遅延帯域幅積のパス上でベストエフォートトラフィックの可能性と限界を理解していません。
There is also a need for long-term research in congestion control that is separate from specific functional requirements like the ones listed above. We know very little about congestion control dynamics or traffic dynamics of a large, complex network like the global Internet, with its heterogeneous and changing traffic mixes, link-level technologies, network protocols and router mechanisms, patterns of congestion, pricing models, and the like. Expanding our knowledge in this area seems likely to require a rich mix of measurement, analysis, simulations, and experimentation.
上に挙げたもののような特定の機能要件から分離された輻輳制御における長期的な研究も必要です。私たちは、その異質と、トラフィックミックス、リンクレベルの技術、ネットワークプロトコルおよびルータの仕組み、渋滞のパターン、価格モデルを変更し、で、輻輳制御のダイナミクスやグローバルなインターネットのような大規模、複雑なネットワークのトラフィックのダイナミクスについてはほとんど知っています好む。この分野で我々の知識を展開すると、測定、解析、シミュレーション、および実験の豊かなミックスを必要とする可能性が高いようです。
The evolution of the Internet infrastructure has been frustratingly slow and difficult, with long stories about the difficulties in adding IPv6, QoS, multicast, and other functionality to the Internet. We need a more scientific understanding of the evolutionary potentials and evolutionary difficulties of the Internet infrastructure.
インターネットインフラの進化は、インターネットへのIPv6、QoSの、マルチキャスト、および他の機能を追加することの難しさについての長い話で、イライラが遅いと困難でした。我々は進化のポテンシャルとインターネットインフラの進化の難しさをより多くの科学的な理解が必要です。
This evolutionary potential is affected not only by the technical issues of the layered IP architecture, but by other factors as well. These factors include the changes in the environment over time (e.g., the recent overprovisioning of backbones, the deployment of firewalls), and the role of the standardization process. Economic and public policy factors are also critical, including the central fact of the Internet as a decentralized system, with key players being not only individuals, but also ISPs, companies, and entire industries. Deployment issues are also key factors in the evolution of the Internet, including the continual chicken-and-egg problem of having enough customers to merit rolling out a service whose utility depends on the size of the customer base in the first place.
この進化の可能性も同様に階層化IPアーキテクチャの技術的な問題によって、他の要因によってだけでなく、影響を受けています。これらの要因は、時間の経過とともに、環境の変化（例えば、バックボーンの最近のオーバープロビジョニング、ファイアウォールの展開）、および標準化プロセスの役割が含まれます。経済と公共政策の要因はキープレーヤーは、個人だけでなく、ISPは、企業、業界全体であることで、分散型システムとしてのインターネットの中心事実を含め、も重要です。展開の問題もその有用性最初の場所での顧客基盤の大きさに依存したサービスを展開メリットに十分な顧客を持っていることの継続的な鶏と卵の問題を含め、インターネットの進化に重要な要因です。
Overlay networks might serve as a transition technology for some new functionality, with an initial deployment in overlay networks, and with the new functionality moving later into the core if it seems warranted.
オーバーレイネットワークは、オーバーレイネットワークの初期の展開と、それが正当と思われる場合は、新しい機能がコアに後で移動すると、いくつかの新しい機能のための移行技術となる恐れがあります。
There are also increased obstacles to the evolution of the Internet in the form of increased complexity [WD02], unanticipated feature interactions [Kruse00], interactions between layers [CWWS92], interventions by middleboxes [RFC-3424], and the like. Because increasing complexity appears inevitable, research is needed to understand architectural mechanisms that can accommodate increased complexity without decreasing robustness of performance in unknown environments, and without closing off future possibilities for evolution. More concretely, research is needed on how to evolve the Internet will still maintaining its core strengths, such as the current degree of global addressability of hosts, end-to-end transparency of packet forwarding, and good performance for best-effort traffic.
複雑化の形でインターネットの進化にも増加の障害[WD02]、予期せぬ機能競合[Kruse00]、各層[CWWS92]、ミドルボックス[RFC-3424]によって介入、などの間の相互作用があります。複雑化が避けられない表示されますので、研究は未知の環境でのパフォーマンスの堅牢性を低下させることなく、そして進化のための将来の可能性を閉鎖することなく、複雑化に対応できるアーキテクチャのメカニズムを理解するために必要とされます。より具体的には、研究は、このようなグローバルなホストのアドレス指定、パケット転送のエンド・ツー・エンドの透明性、およびベストエフォートトラフィックのための良好なパフォーマンスの現在の程度として、まだその強みを維持しますインターネットを進化させる方法について必要とされています。
Research is needed to address the challenges posed by the wide range of middleboxes [RFC-3234]. This includes issues of security, control, data integrity, and on the general impact of middleboxes on the architecture.
研究は、ミドルボックス[RFC-3234]の広い範囲によってもたらされる課題に対処するために必要とされます。これは、セキュリティ、制御、データの整合性、およびアーキテクチャ上のミドルボックスの一般的な影響についての問題を含んでいます。
In many ways middleboxes are a direct outgrowth of commercial interests, but there is a need to look beyond the near-term needs for the technology, to research its broader implications and to explore ways to improve how middleboxes are integrated into the architecture.
多くの点でミドルボックスは、商業的利益の直接伸長しているが、その広い意味合いを研究し、ミドルボックスは、アーキテクチャに統合されている方法を改善する方法を模索するために、技術のための短期的なニーズを越えて見る必要があります。
A recurring challenge is measuring the Internet; there have been many discussions about the need for measurement studies as an integral part of Internet research [Claffy03]. In this discussion, we define measurement quite broadly. For example, there are numerous challenges in measuring performance along any substantial Internet path, particularly when the path crosses administrative domain boundaries. There are also challenges in measuring protocol/application usage on any high-speed Internet link. Many of the problems discussed above would benefit from increased frequency of measurement as well as improved quality of measurement on the deployed Internet.
定期的な課題は、インターネットを測定しています。インターネット調査[Claffy03]の不可欠な一部として測定研究の必要性について多くの議論がなされています。この議論では、我々は非常に広く、測定を定義します。たとえば、パスは管理ドメインの境界を横切る場合は特に、実質的なインターネットの経路に沿ってパフォーマンスを測定するには多くの課題があります。任意の高速インターネットリンク上のプロトコル/アプリケーションの使用状況を測定する際の課題もあります。上述の問題の多くは、測定の頻度の増加、ならびに展開インターネット上の測定の品質向上から恩恵を受ける。
A key issue in network measurement is that most commercial Internet Service Providers consider the particular characteristics of their production IP network(s) to be trade secrets. Ways need to be found for cooperative measurement studies, e.g., to allow legitimate non-commercial researchers to be able to measure relevant network parameters while also protecting the privacy rights of the measured ISPs.
ネットワーク測定における重要な問題は、ほとんどの商用インターネットサービスプロバイダは、企業秘密であることをその生産IPネットワーク（複数可）の特定の特性を検討することです。方法は、正当な非商用の研究者はまた、測定のISPのプライバシーの権利を保護しながら、関連するネットワークパラメータを測定できることができるように、例えば、協力測定研究のために発見される必要があります。
Absent measured data, there is possibly an over-reliance on network simulations in some parts of the Internet research community and probably insufficient validation that existing network simulation models are reasonably good representations of the deployed Internet (or of some plausible future Internet) [FK02].
不在の測定データは、既存のネットワークのシミュレーションモデルが展開され、インターネットの適度に良好な表現であることをおそらくインターネットリサーチコミュニティの一部でネットワークシミュレーション上の過度の依存、おそらく不十分な検証がある（またはいくつかのもっともらしい将来のインターネットの）[FK02] 。
Without solid measurement of the current Internet behavior, it is very difficult to know what otherwise unknown operational problems exist that require attention, and it is equally difficult to fully understand the impact of changes (past or future) upon the Internet's actual behavioral characteristics.
現在のインターネット行動の固体測定がなければ、そうでない場合は、未知の操作上の問題が注意を必要とする存在かを知ることは非常に困難であり、完全にインターネットの実際の行動特性に変化（過去または未来）の影響を理解することも同様に困難です。
Research is needed on a wide range of issues related to Internet applications.
調査はインターネットアプリケーションに関連する問題の広い範囲で必要とされています。
Taking email as one example application, research is needed on understanding the spam problem, and on investigating tools and techniques to mitigate the effects of spam, including tools and techniques that aid the implementation of legal and other non-technical anti-spam measures [ASRG]. "Spam" is a generic term for a range of significantly different types of unwanted bulk email, with many types of senders, content and traffic-generating techniques. As one part of controlling spam, we need to develop a much better understanding of its many, different characteristics and their interactions with each other.
1例のアプリケーションとして電子メールを撮影、研究は、スパム問題を理解することにし、[ASRGを、スパムの影響を軽減するためのツールとテクニックを調査し、法的及びその他の非技術的なアンチスパム対策の実施を支援するツールや手法を含めた上で必要とされています]。 「スパム」送信者、コンテンツとトラフィック生成技術の多くの種類との望ましくない大量のメールの大きく異なるタイプの範囲の総称です。スパム制御の一環として、私たちはお互いにその多くの、異なる特性とその相互作用のより良い理解を開発する必要があります。
As network size, link bandwidth, CPU capacity, and the number of users all increase, research will be needed to ensure that the Internet of the future scales to meet these increasing demands. We have discussed some of these scaling issues in specific sections above.
ネットワークサイズ、リンク帯域幅、CPUの能力、およびユーザの数すべて増加すると、研究は、将来のインターネットは、これらの増大する需要を満たすためにスケールすることを保証するために必要とされるであろう。私たちは、上記の特定のセクションでは、これらのスケーリング問題のいくつかを議論してきました。
However, for all of the research questions discussed in this document, the goal of the research must be not only to meet the challenges already experienced today, but also to meet the challenges that can be expected to emerge in the future.
しかし、この文書で説明する研究課題のすべてのために、研究の目標は、すでに今日経験した課題に対応するために、だけでなく、将来的に出現することが期待される課題に対応するだけでなく、でなければなりません。
U.S.'s DARPA has historically funded development of freely distributable implementations of various Internet technologies (e.g., TCP/IPv4, RSVP, IPv6, and IP security) in a variety of operating systems (e.g., 4.2 BSD, 4.3 BSD, 4.4 BSD, Tenex). Experience has shown that a good way to speed deployment of a new technology is to provide an unencumbered, freely-distributable prototype that can be incorporated into commercial products as well as non-commercial prototypes. Japan's WIDE Project has also funded some such work, primarily focused on IPv6 implementation for 4.4 BSD and Linux. [WIDE] We believe that applied research projects in networking will have an increased probability of success if the research project teams make their resulting software implementations freely available for both commercial and non-commercial uses. Examples of successes here include the DARPA funding of TCP/IPv4 integration into the 4.x BSD operating system [MBKQ96], DARPA/USN funding of ESP/AH design and integration into 4.4 BSD [Atk96], as well as separate DARPA/USN and WIDE funding of freely distributable IPv6 prototypes [Atk96, WIDE].
米国のDARPAは、歴史的に、オペレーティング・システム（例えば、4.2 BSD、4.3 BSD、4.4 BSD、TENEXの様々な様々なインターネット技術（例えば、TCP / IPv4の、RSVP、IPv6、およびIPセキュリティ）の自由に配布可能な実装の開発に資金を提供しています）。経験は、新技術の導入を迅速化するための良い方法は、市販品としてだけでなく、非商用のプロトタイプに組み込むことができ邪魔されない、自由に配布可能なプロトタイプを提供することであることが示されています。日本のWIDEプロジェクトはまた、主に4.4 BSDとLinux用のIPv6の実装に焦点を当て、そのようないくつかの作業に資金を提供しています。 [WIDE]私たちは、研究プロジェクトチームは、両方の商業および非商業的利用のための彼らの結果のソフトウェア実装が自由に利用できるようにする場合は、ネットワーキングにおける応用研究プロジェクトが成功する確率の増加を持っていると確信しています。成功例は、ここに4.4 BSD [Atk96]に4.xのBSDオペレーティングシステム[MBKQ96]、ESP / AHの設計および統合のDARPA / USNの資金へのTCP / IPv4の統合のDARPAの資金を含み、ならびに別個のDARPA / USNそして自由に配布IPv6のプロトタイプのWIDE資金調達[Atk96、WIDE]。
This document has summarized the history of research funding for the Internet and highlighted examples of open research questions. The IAB believes that more research is required to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research.
この文書は、インターネットのための研究資金の歴史をまとめ、オープン研究課題の例を強調しています。 IABは、より多くの研究は、インターネットインフラの進化を促進するために必要であることを信じて、その一貫性のある、十分な非商業的資金は、そのような研究を可能にするために必要とされています。
In case there is any confusion, in this document we are not suggesting any direct or indirect role for the IAB, the IETF, or the IRTF in handling any funding for Internet research.
場合には、この文書では、我々はインターネット調査のための任意の資金を取り扱う際のIAB、IETF、またはIRTFのための任意の直接的または間接的な役割を示唆していない、任意の混乱があります。
The people who directly contributed to this document in some form include the following: Ran Atkinson, Guy Almes, Rob Austein, Vint Cerf, Jon Crowcroft, Sally Floyd, James Kempf, Joe Macker, Craig Partridge, Vern Paxson, Juergen Schoenwaelder, and Mike St. Johns.
直接何らかの形でこの文書に貢献し、人々は、次のものがありますアトキンソン、ガイAlmes、ロブAusteinと、ヴィントン・サーフ、ジョンクロウクロフト、サリー・フロイド、ジェームズ・ケンプ、ジョーMacker、クレイグ・パートリッジ、バーン・パクソン、ユルゲンSchoenwaelder、およびマイク・蘭セントジョンズ。
We are also grateful to Kim Claffy, Dave Crocker, Michael Eder, Eric Fleischman, Andrei Gurtov, Stephen Kent, J.P. Martin-Flatin, and Hilarie Orman for feedback on earlier drafts of this document.
私たちは、この文書の以前のドラフトのフィードバックのためにキムClaffy、デイブ・クロッカー、マイケル・エダー、エリックFleischman、アンドレイGurtov、スティーブン・ケント、J.P.マーティン・Flatin、およびヒラリーオーマンにも感謝しています。
We have also drawn from the following reports: [CIPB02,IST02,NV02,NSF02,NSF03,NSF03a].
[CIPB02、IST02、NV02、NSF02、NSF03、NSF03a]：我々はまた、次のレポートから引き出されています。
This document does not itself create any new security issues for the Internet community. Security issues within the Internet Architecture primarily are discussed in Section 3.4 above.
この文書は、それ自体は、インターネットコミュニティのための新たなセキュリティ問題を作成しません。インターネットアーキテクチャ内のセキュリティの問題は、主に上記の3.4節で議論されています。
[ASRG] Anti-Spam Research Group (ASRG) of the IRTF. URL "http://asrg.sp.am/".
IRTFの[ASRG]アンチスパム研究グループ（ASRG）。 URL "http://asrg.sp.am/"。
[Atk96] R. Atkinson et al., "Implementation of IPv6 in 4.4 BSD", Proceedings of USENIX 1996 Annual Technical Conference, USENIX Association, Berkeley, CA, USA. January 1996. URL http://www.chacs.itd.nrl.navy.mil/publications/CHACS/ 1996/1996atkinson-USENIX.pdf
[Atk96] R.アトキンソンら、 "4.4 BSDでのIPv6の実装"、USENIX 1996年次技術会議、USENIX協会、バークレー、CA、USAの議事。 1996年1月URL http://www.chacs.itd.nrl.navy.mil/publications/CHACS/ 1996 / 1996atkinson-USENIX.pdf
[Bellman1957] R.E. Bellman, "Dynamic Programming", Princeton University Press, Princeton, NJ, 1957.
【Bellman1957] R.E.ベルマン、 "ダイナミックプログラミング"、プリンストン大学プレス、プリンストン、NJ、1957。
[Claffy03] K. Claffy, "Priorities and Challenges in Internet Measurement, Simulation, and Analysis", Large Scale Network meeting, (US) National Science Foundation, Arlington, VA, USA. 10 June 2003. URL "http://www.caida.org/outreach/ presentations/2003/lsn20030610/".
[Claffy03] K. Claffy、「優先順位およびインターネット計測、シミュレーション、および分析の課題」、大規模ネットワーク会議、（米国）国立科学財団、アーリントン、VA、USA。 2003年6月10日URL "http://www.caida.org/outreach/プレゼンテーション/ 2003 / lsn20030610 /"。
[Claffy03a] K. Claffy, "Top Problems of the Internet and What Sysadmins and Researchers Can Do To Help", plenary talk at LISA'03, October 2003. URL "http://www.caida.org/outreach/presentations/ 2003/netproblems_lisa03/".
[Claffy03a] K. Claffy、「トップインターネットの問題点と助けるためにどのようなシステム管理者や研究者でできること」、本会議の話LISA'03で、2003年10月URL「http://www.caida.org/outreach/presentations/ 2003 / netproblems_lisa03 /」。
[Clark02] D. D. Clark, "Deploying the Internet - why does it take so long and, can research help?", Large-Scale Networking Distinguished Lecture Series, (U.S.) National Science Foundation, Arlington, VA, 8 January 2002. URL: http://www.ngi-supernet.org/conferences.html
[Clark02] DDクラークは、「インターネットを展開する - なぜそれが助けを調べることができ、とても長い時間がかかるとしますか？」、大規模ネットワーク識別レクチャーシリーズ、（米国）国立科学財団、バージニア州アーリントン、1月8日2002年URL： http://www.ngi-supernet.org/conferences.html
[CSTB99] Computer Science and Telecommunications Board, (U.S.) National Research Council, "Funding a Revolution: Government Support for Computing Research", National Academy Press, Washington, DC, 1999. URL "http://www7.nationalacademies.org/cstb/ pub_revolution.html".
[CSTB99]コンピュータサイエンスと電気通信委員会、（米国）国立研究評議会、「革命資金調達：コンピューティングの研究のための政府の支援」、米国アカデミープレス、ワシントンD.C.、1999年URL「http://www7.nationalacademies.org/ CSTB / pub_revolution.html」。
[CIPB02] Critical Infrastructure Protection Board, "National Strategy to Secure Cyberspace", The White House, Washington, DC, USA. September 2002, URL "http://www.whitehouse.gov/pcipb".
[CIPB02]重要インフラ保護委員会、ホワイトハウス、ワシントンD.C.、USA「国家戦略は、サイバースペースを確保するために」。 2002年9月、URL "http://www.whitehouse.gov/pcipb"。
[CWWS92] J. Crowcroft, I. Wakeman, Z. Wang, and D. Sirovica, "Is Layering Harmful?", IEEE Networks, Vol. 6, Issue 1, pp 20-24, January 1992.
[CWWS92] J.クロウクロフト、I.ウェイクマン、Z.王、およびD. Sirovica、 "有害階層化されていますか"、IEEEネットワーク、巻。 6、1号、頁20-24、1992年1月。
[Diot00] C. Diot, et al., "Deployment Issues for the IP Multicast Service and Architecture", IEEE Network, January/February 2000.
[Diot00] C. Diot、ら、 "IPマルチキャストサービスとアーキテクチャの展開に関する問題"、IEEEネットワーク、1月/ 2000年2月。
[Deering1988] S. Deering, "Multicast Routing in Internetworks and LANs", ACM Computer Communications Review, Volume 18, Issue 4, August 1988.
[Deering1988] S.デアリング、 "インターネットワークとのLANでマルチキャストルーティング"、ACMコンピュータコミュニケーションレビュー、18巻、4号、1988年8月。
[Dijkstra59] E. Dijkstra, "A Note on Two Problems in Connexion with Graphs", Numerische Mathematik, 1, 1959, pp.269-271.
【Dijkstra59】E.ダイクストラ、 "グラフとConnexionの中に二つの問題に注意"、Numerische Mathematik、1、1959、pp.269-271。
[FF1962] L. R. Ford Jr. and D.R. Fulkerson, "Flows in Networks", Princeton University Press, Princeton, NJ, 1962.
【FF1962] L. R.フォード・ジュニアとD.R.フルカーソンは、プリンストン大学プレス、プリンストン、NJ、1962年には、「ネットワークに流れます」。
[FK02] S. Floyd and E. Kohler, "Internet Research Needs Better Models", Proceedings of 1st Workshop on Hot Topics in Networks (Hotnets-I), Princeton, NJ, USA. October 2002. URL "http://www.icir.org/models/bettermodels.html".
ネットワークのホットな話題の[FK02] S.フロイドおよびE.コーラー、「インターネットリサーチは、より良いモデルが必要」、第1回ワークショップの議事録（Hotnets-I）、プリンストン、NJ、USA。 2002年10月URL "http://www.icir.org/models/bettermodels.html"。
[IM1993] J. Ioannidis and G. Maguire Jr., "The Design and Implementation of a Mobile Internetworking Architecture", Proceedings of the Winter USENIX Technical Conference, pages 489-500, Berkeley, CA, USA, January 1993.
[IM1993] J. IoannidisとG.マグワイア・ジュニア、「モバイルインターネットワーキングアーキテクチャの設計と実装」、冬のUSENIX技術会議、ページ489-500、バークレー、CA、USA、1993年1月の議事。
[IST02] Research Networking in Europe - Striving for Global Leadership, Information Society Technologies, 2002. URL "http://www.cordis.lu/ist/rn/rn-brochure.htm".
[IST02]ヨーロッパの研究ネットワークは - グローバル・リーダーシップ、情報社会・テクノロジーズ、2002年URL「http://www.cordis.lu/ist/rn/rn-brochure.htm」を目指して。
[Jacobson88] Van Jacobson, "Congestion Avoidance and Control", Proceedings of ACM SIGCOMM 1988 Symposium, ACM SIGCOMM, Stanford, CA, August 1988. URL "http://citeseer.nj.nec.com/jacobson88congestion.html".
[Jacobson88]バン・ジェイコブソン、 "輻輳回避とコントロール"、ACMのSIGCOMM 1988シンポジウム、ACM SIGCOMM、スタンフォード大学、カリフォルニア州、1988年8月URL "http://citeseer.nj.nec.com/jacobson88congestion.html" の議事録。
[Jackson02] William Jackson, "U.S. should fund R&D for secure Internet protocols, Clarke says", Government Computer News, 31 October 2002. URL "http://www.gcn.com/vol1_no1/security/20382-1.html".
[Jackson02]ウィリアム・ジャクソン、「米国は安全なインターネット・プロトコルのためのR＆Dに資金を供給する必要があり、クラークは言う」、政府のコンピュータのニュース、10月31日2002年URL「http://www.gcn.com/vol1_no1/security/20382-1.html」 。
[Kruse00] Hans Kruse, "The Pitfalls of Distributed Protocol Development: Unintentional Interactions between Network Operations and Applications Protocols", Proceedings of the 8th International Conference on Telecommunication Systems Design, Nashville, TN, USA, March 2000. URL "http://www.csm.ohiou.edu/kruse/publications/ TSYS2000.pdf".
[Kruse00]ハンス・クルーゼ、「分散プロトコル開発の落とし穴：ネットワークオペレーションとアプリケーションプロトコル間の意図しない相互作用」、通信システムの設計、ナッシュビル、テネシー州、アメリカ、2000年3月URLは「http第8回国際会議の議事録：// www.csm.ohiou.edu/kruse/publications/ TSYS2000.pdf」。
[KLMS2000] S. Kent, C. Lynn, J. Mikkelson, and K. Seo, "Secure Border Gateway Protocol (S-BGP)", Proceedings of ISOC Network and Distributed Systems Security Symposium, Internet Society, Reston, VA, February 2000.
【KLMS2000] S.ケント、C.リン、J. Mikkelson、及びK.ソ、「ボーダーゲートウェイプロトコル（S-BGP）を確保」、ISOCネットワークの議事と分散システムセキュリティシンポジウム、インターネット協会、レストン、バージニア州2月2000。
[LD2002] E. Lear and R. Droms, "What's in a Name: Thoughts from the NSRG", expired Internet-Draft, December 2002.
[LD2002] E.リアとR. Droms、「どのような名前である：NSRGからの思考は、」、インターネットドラフト、2002年12月に失効しました。
[MBFIPS01] Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker, "Controlling High Bandwidth Aggregates in the Network", ACM Computer Communications Review, Vol. 32, No. 3, July 2002. URL "http://www.icir.org/pushback/".
[MBFIPS01] Ratulマハジャン、スティーブンM. Bellovin氏、サリー・フロイド、ジョン・P・A・ヨアニディス、バーン・パクソン、およびスコット・シェンカー、「ネットワークでの制御高帯域幅集約」、ACMコンピュータコミュニケーションレビュー、巻。 32、第3号、2002年7月URL "http://www.icir.org/pushback/"。
[MBKQ96] M. McKusick, K. Bostic, M. Karels, and J. Quarterman, "Design and Implementation of the 4.4 BSD Operating System", Addison-Wesley, Reading, MA, 1996.
【MBKQ96] M. McKusickが、K.ボスティック、M. Karels、及びJ. Quarterman、アディソン・ウェスリー、リーディング、MA、1996 "4.4 BSDオペレーティングシステムの設計と実装"。
[MGVK02] Z. Mao, R. Govindan, G. Varghese, & R. Katz, "Route Flap Dampening Exacerbates Internet Routing Convergence", Proceedings of ACM SIGCOMM 2002, ACM, Pittsburgh, PA, USA, August 2002.
[MGVK02] Z.真央、R.ゴヴィンダン、G. Varghese、＆R.カッツ、 "ルートフラップダンプニングの悪化インターネットルーティングコンバージェンス"、ACMのSIGCOMM 2002の議事録、ACM、ピッツバーグ、PA、USA、2002年8月。
[NV02] NetVision 2012 Committee,"DARPA's Ten-Year Strategic Plan for Networking Research", (U.S.) Defense Advanced Research Projects Agency, October 2002. Citation for acknowledgement purposes only.
[NV02] NetVision 2012委員会、「ネットワーキング研究DARPAの10年戦略計画」、（米国）米国防総省の国防高等研究計画庁、確認のみを目的とした2002年10月の引用。
[NSF02] NSF Workshop on Network Research Testbeds, National Science Foundation, Directorate for Computer and Information Science & Engineering, Advanced Networking Infrastructure & Research Division, Arlington, VA, USA, October 2002. URL "http://www-net.cs.umass.edu/testbed_workshop/".
[NSF02]ネットワーク研究テストベッド上のNSFワークショップ、国立科学財団、コンピュータと情報科学＆工学総局、高度なネットワークインフラ・研究部門、アーリントン、VA、USA、2002年10月URLは「http：//www-net.cs .umass.edu / testbed_workshop /」。
[NSF03] NSF ANIR Principal Investigator meeting, National Science Foundation, Arlington, VA, USA. January 9-10, 2003, URL "http://www.ncne.org/training/nsf-pi/2003/nsfpimain.html".
[NSF03] NSFのANIR主任研究会、国立科学財団、アーリントン、VA、USA。 1月9-10、2003、URL "http://www.ncne.org/training/nsf-pi/2003/nsfpimain.html"。
[NSF03a] D. E. Atkins, et al., "Revolutionizing Science and Engineering Through Cyberinfrastructure", Report of NSF Advisory Panel on Cyberinfrastructure, January 2003. URL "http://www.cise.nsf.gov/evnt/reports/ atkins_annc_020303.htm".
[NSF03a] DEアトキンスら、「サイバーインフラストラクチャを通じて変革科学と工学」、サイバーインフラストラクチャ上のNSF諮問委員会の報告書、2003年1月URL「http://www.cise.nsf.gov/evnt/reports/ atkins_annc_020303。 HTM」。
[NSF03b] Report of the National Science Foundation Workshop on Fundamental Research in Networking. April 24-25, 2003. URL "http://www.cs.virginia.edu/~jorg/workshop1/NSF-NetWorkshop-2003.pdf".
ネットワークにおける基礎研究の国立科学財団ワークショップの[NSF03b]レポート。 4月24-25日、2003年URL "http://www.cs.virginia.edu/~jorg/workshop1/NSF-NetWorkshop-2003.pdf"。
[Floyd] S. Floyd, "Papers about Research Questions for the Internet", web page, ICSI Center for Internet Research (ICIR), Berkeley, CA, 2003 URL "http://www.icir.org/floyd/research_questions.html".
[フロイド] S.フロイド、Webページ、インターネットリサーチ（ICIR）についてICSIセンター、バークレー、CA、2003 URL「http://www.icir.org/floyd/research_questions "インターネットのための研究課題に関する論文"。 HTML」。
[RFC-1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC-1510]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月。
[RFC-1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC-1633]ブレーデン、R.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC-2082] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
[RFC-2082]ベーカー、F.とR.アトキンソン、 "RIP-2 MD5認証"、RFC 2082、1997年1月。
[RFC-2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC-2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC-2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC-2154]マーフィー、S.、アナグマ、M.、およびB.ウェリントン、 "デジタル署名とOSPF"、RFC 2154、1997年6月。
[RFC-2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC-2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC-2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC-2407]パイパー、D.、RFC 2407 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、1998年11月。
[RFC-2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999.
[RFC-2501]コルソン、S.とJ. Macker、 "モバイルアドホックネットワーク（MANET）：ルーティングプロトコルのパフォーマンスに関する問題や評価に関する注意事項"、RFC 2501、1999年1月。
[RFC-2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC-2990]ヒューストン、G.、 "IP QoSのアーキテクチャーのための次のステップ"、RFC 2990、2000年11月。
[RFC-3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC-3221]ヒューストン、G.、 "インターネットにおけるドメイン間ルーティングの解説"、RFC 3221、2001年12月。
[RFC-3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC-3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
[RFC-3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC-3424] Daigle氏、L.とIAB、 "一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）ネットワークアドレス変換アクロス"、RFC 3424、2002年11月。
[RFC-3467] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, February 2003.
[RFC-3467] Klensin、J.、RFC 3467、2003年2月 "ドメインネームシステム（DNS）の役割"。
[RFC-3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003.
[RFC-3535] Schoenwaelder、J.、RFC 3535、2003年5月 "2002 IABネットワーク管理ワークショップの概要" を参照してください。
[RFC-3387] Eder, M., Chaskar, H., and S. Nag, "Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network", RFC 3387, September 2002.
[RFC-3387]エダー、M.、Chaskar、H.、およびS.ナグ、RFC 3387 "サービス品質IPネットワーク内（QoS）の上のサービス管理研究グループ（SMRG）からの注意事項"、2002年9月。
[RIPE] RIPE (Reseaux IP Europeens), Amsterdam, NL. URL "http://www.ripe.net/ripe/".
[RIPE] RIPE（IPネットワークヨーロッパ）、アムステルダム、NL。 URL "http://www.ripe.net/ripe/"。
[Savage00] Savage, S., Wetherall, D., Karlink, A. R., and Anderson, T., "Practical Network Support for IP Traceback", Proceedings of 2000 ACM SIGCOMM Conference, ACM SIGCOMM, Stockholm, SE, pp. 295-306. August 2000.
[Savage00]サベージ、S.、Wetherall、D.、Karlink、AR、およびアンダーソン、T.、2000年ACM SIGCOMM会議議事録、ACM SIGCOMM、ストックホルム、SE、頁 "IPトレースバックのための実用的なネットワークのサポート"。295- 306。 2000年8月。
[Schiller03] J. I. Schiller, "Interception Technology: The Good, The Bad, and The Ugly!", Presentation at 28th NANOG Meeting, North American Network Operators Group (NANOG), Ann Arbor, MI, USA, June 2003. URL "http://www.nanog.org/mtg-0306/schiller.html".
[Schiller03] JIシラー、「傍受技術：！続・夕陽のガンマン」、第28回NANOGミーティング、北アメリカネットワークオペレータグループ（NANOG）、アナーバー、MI、USA、2003年6月URL「でのプレゼンテーションのhttp ：「//www.nanog.org/mtg-0306/schiller.html。
[SM03] P. Sharma and R. Malpani, "IP Multicast Operational Network Management: Design, Challenges, and Experiences", IEEE Network, Vol. 17, No. 2, March 2003.
[SM03] P.シャルマとR. Malpani、 "IPマルチキャスト運用ネットワーク管理：デザイン、課題、および経験"、IEEEネットワーク、巻。 17、第2号、2003年3月。
[SMA03] N. Spring, R. Mahajan, & T. Anderson, "Quantifying the Causes of Path Inflation", Proceedings of ACM SIGCOMM 2003, ACM, Karlsruhe, Germany, August 2003.
[SMA03] N.春、R.マハジャン、＆T.アンダーソン、 "パスのインフレの原因を定量化"、ACMのSIGCOMM 2003の議事録、ACM、カールスルーエ、ドイツ、2003年8月。
[WD02] Walter Willinger and John Doyle, "Robustness and the Internet: Design and Evolution", Unpublished/Preprint, 1 March 2002, URL "http://netlab.caltech.edu/internet/".
[WD02]ウォルターWillingerとジョン・ドイル、 "堅牢性とインターネット：設計と進化"、未発表/予稿集、2002年3月1日、URL "http://netlab.caltech.edu/internet/"。
[WIDE] WIDE Project, Japan. URL "http://www.wide.ad.jp/".
[WIDE] WIDEプロジェクト、日本。 URL "http://www.wide.ad.jp/"。
Internet Architecture Board EMail: iab@iab.org
インターネットアーキテクチャ委員会メールアドレス：iab@iab.org
Internet Architecture Board Members at the time this document was published were:
インターネットアーキテクチャ委員会のメンバーは、この文書が発行された時点でした。
Bernard Aboba Harald Alvestrand (IETF chair) Rob Austein Leslie Daigle (IAB chair) Patrik Faltstrom Sally Floyd Mark Handley Bob Hinden Geoff Huston (IAB Executive Director) Jun-ichiro Itojun Hagino Eric Rescorla Pete Resnick Jonathan Rosenberg
バーナードAbobaハラルドAlvestrand（IETFいす）ロブAusteinとレスリーDaigle氏（IABいす）パトリックFaltstromサリーフロイドマーク・ハンドリーボブHindenとジェフ・ヒューストン（IABエグゼクティブ・ディレクター）6月-一郎いとぢゅん萩野エリックレスコラピートレズニックジョナサン・ローゼンバーグ
We note that Ran Atkinson, one of the editors of the document, was an IAB member at the time that this document was first created, in November 2002, and that Vern Paxson, the IRTF chair, is an ex-officio member of the IAB.
私たちは、アトキンソン、文書の編集者の一人蘭2002年11月に、この文書が最初に作成された時点で、IABのメンバーだった、とバーン・パクソン、IRTFの椅子は、IABの充て職であることことに注意してください。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。