[要約] RFC 3869は、インターネットの研究と進化に関するIABの懸念と推奨事項をまとめたものです。このRFCの目的は、インターネットの研究における課題や問題点を明確にし、進化のための推奨事項を提供することです。
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
IABインターネット調査と進化に関する懸念と推奨事項
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）The Internet Society（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番目の部分は、オープンなインターネット調査のトピックの不完全なセットを提供します。これらは、オープンな研究トピックの幅を示すことを目的とした例のみです。この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（インターネットリサーチタスクフォース）のアジェンダに関連するトピックに焦点を当てています。（たとえば、Gridの問題は、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.
パケットスイッチネットワークの初期の研究のほとんどは、米国防衛先進研究プロジェクト局（DARPA）[CSTB99]が後援しました。これには、いくつかの大学やその他のDARPA請負業者を接続するArpanetの初期設計、実装、および展開が含まれます。Arpanetはもともと1960年代後半にオンラインになりました。1970年代には規模が大きくなりましたが、主にDARPAの資金提供を受けており、パケットスイッチのネットワーキングの有用性を実証しました。
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の資金は、最初のArpanet展開のわずか4年後の1973年に始まりました。インターネット設計のサポートは、パケットラジオおよびパケット衛星研究の以前のDARPA資金の1つでした。複数のネットワーク（Arpanet、Packet Radio、およびPacket Satellite）の存在により、インターネットワーク調査の必要性が促進されました。インターネットは、これら3つのネットワークに対するDARPAの研究資金の結果として大規模に発生しました。偶然にも、イーサネット上のXerox 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は引き続き主要な資金源ですが、他のDOD（米国国防総省）の資金提供（たとえば、防衛通信機関（DCA）の防衛データネットワーク（DDN）プログラムを介して）および他の米国政府の資金（例：、米国エネルギー省（DOE）DOE National Laboratories（米国）国立科学財団（NSF）の学術機関の資金提供）の研究ネットワークの資金。この資金には、基礎研究、応用研究（自由分散型プロトタイプを含む）、IP対応製品の購入、Arpanet、Esnet、Milnet、The NASA Science Internet、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年代に、米国のDODは、学術機関に運用上のネットワークサービスを提供するビジネスを離れることを望んでいたため、ほとんどの学術活動への資金提供は10年間にNSFに移動しました。NSFの最初の作業には、1981年のCSNETのスポンサーシップが含まれていました。1986年までに、NSFはさまざまな研究プロジェクトをネットワーキング（たとえば、ファズボールに関するミルズの作業）のスポンサーにしていました。1980年代後半、NSFはNSFNETバックボーンを作成し、いくつかのNSF地域ネットワーク（Suranetなど）の作成といくつかの国際的な研究ネットワークとの相互接続を後援しました。NSFはまた、1980年代後半から、Corporation for National Research Initiatives（CNRI）を通じてGigabit Networking Researchに資金を提供しました。NSFのスポンサーシップは、大学の科学者をNSFスーパーコンピューティングセンターに接続するなど、コアNSFの目標を達成することに焦点を当てていることに注意することが重要です。スーパーコンピューターへの高性能リモートアクセスのニーズにより、NSFNET全体のパフォーマンスが促進されました。副作用として、これは、これらの大学の学生と教員が比較的高いパフォーマンスのインターネット環境を享受したことを意味しました。それらの学生が卒業するにつれて、彼らはインターネットの商業的利用と新生の住宅市場の両方を推進しました。これがWorld Wide Webが出現した環境であることは偶然ではありません。
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ネットワーキングプロジェクトまたは当時の新しい形態のネットワークメディア（例：ワイヤレス、ブロードバンドアクセス）に焦点を当てていました。欧州連合は、この期間中にヨーロッパのネットワーキングコミュニティにとって重要な研究資金源でした。ギガビットネットワーキングで最高の初期の仕事のいくつかが英国とスウェーデンで行われました。
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年代半ばから、インターネット研究開発のための米国政府の資金は大幅に減少しました。これの前提は、成長するインターネット業界が必要な研究開発に支払うことでした。この期間には、ヨーロッパおよびアジアの組織（日本の幅広いプロジェクト[ワイド]）から、インターネットの研究開発のための資金が継続されています。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.
この期間中の経験は、商業企業が学術機関に機器を寄付し、多少職業的に焦点を当てた教育プロジェクトを促進することに焦点を当てていることが多いことです。商業的に資金提供された研究開発プロジェクトの多くは、資金源に競合他社よりも特定の短期的な経済的優位性を与える可能性が高いと思われるため、選択されたようです。より高いリスク、より革新的な研究提案は一般に業界によって資金提供されていません。シリコンバレーの一般的な見解は、設立された商業会社が製品に最先端の研究を移行するのがあまり得意ではないが、そのような最先端の研究を製品にうまく移行した小規模なスタートアップ企業を購入するのが得意だったということです。残念ながら、中小企業は一般に、自分で研究に資金を提供することができません。
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].
さらなる調査に値するインターネットの問題に関するその他の議論には、次のものが含まれます。
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では、中間断片化は許可されておらず、PATH MTU発見が義務付けられています。ただし、DNSサーバーにIPv6のPATH 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.
これの意味の1つは、各サーバーを使用しているクライアントが非常に多い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.
さらに、インターネット研究タスクフォース（IRTF）の名前空間研究グループ（NSRG）は、インターネットアーキテクチャ[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.
現在展開されているユニキャストルーティングシステムは、ほとんどのユーザーにとって合理的に機能します。ただし、現在のユニキャストルーティングアーキテクチャは、以下を含むいくつかの領域で次のとおりです。グローバルスケールのカテネット（ゲートウェイを介して相互接続されたネットワークのシステム）のエンドツーエンド収束時間。既存のドメイン間パスベクトルアルゴリズムが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テクノロジーは、最長のPrefix-Match計算を実行するのに必要な時間に関する懸念も解消します。ただし、インターネットルーティングコミュニティの一部の上級メンバーは、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など）に依存しているため、インターネット全体に展開するのが難しいようです。ドメイン内ルーティングに関する同様の提案（例：デジタル署名を備えたOSPF、[RFC-2154]）は、大規模なネットワークに展開するのに計算的に実行不可能であると主張されています。
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アプリケーションで使用される信頼のWeb）を使用する能力は、漸進的な展開を促進し、ルーティングシステムの集中管理に関する既存の懸念を解決する可能性があるため、追加の研究と考慮に値します。
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つのアルゴリズムに依存しています。Link-State Routingは、Dijkstraアルゴリズム[Dijkstra59]を使用します。距離ベクトルルーティング（RIPなど）およびパスベクトルルーティング（BGPなど）は、Bellman-Fordアルゴリズム[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.
現在展開されているマルチキャストルーティングは、ディアリングRPFアルゴリズム[Deering1988]に依存しています。代替マルチキャストルーティングアルゴリズムとプロトコルに関する継続的な研究は、マルチキャストルーティングのスケーラビリティに関する現在の懸念を軽減するのに役立つ可能性があります。
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.
展開されたインターネットルーティングシステムは、最短パスが常に最良のパスであると想定しています。これは確かに間違っていますが、現在利用可能なルーティングプロトコルを考えると、合理的な妥協です。インターネットには、代替メトリックを使用したポリシーベースのルーティングまたはルーティングのための展開可能なアプローチがありません（つまり、目的地へのホップ数以外のメトリック）。代替ポリシーの例は次のとおりです。パケット損失の可能性が最も低いパス。ジッターが最小化されたパス。そして、最小化されたレイテンシのパス。また、ポリシーメトリックはビジネス関係を考慮する必要があります。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.
このトピックには、さまざまな問題が含まれています。部分的または完全に自己組織化するルーティングシステム（関連するENDノードを含む）のより分散した動的な性質は、独自のセキュリティの課題を作成します（特に認可、認証、会計、および主要な管理に関連する）。ワイヤレスネットワークのスケーラビリティは、測定または達成するのが難しい場合があります。強制階層は1つのアプローチですが、非常に制限される可能性があります。代替、ワイヤレススケーラビリティに対する制約の少ないアプローチが望まれます。ワイヤレスリンク層プロトコルには通常、リンクの品質、サブレイヤー混雑条件、一時的なチャネル動作などの現在のリンク特性に関する知識があるため、ネットワーク層ルーティングにそのようなデータを使用できるようにする方法を見つけることが望ましいです。これにより、適切な階層化がどうあるべきか、どのレイヤーに機能するべきか、また実際の実装でそのような情報共有がどのようにどのように発生するかについての実際的な考慮事項の建築的疑問が生じます。
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-of-Trustモデルなど）のより正式な研究をすることは有益です。階層的信頼モデルを使用すると、インターネット間のコンポーネント、たとえばドメイン間ルーティングシステムなどのセキュリティにアプローチする方法に大きな制限が生じる可能性があります。したがって、既存のインターネットの問題に対する既存の非階層トラストモデルの適用性に適した新しい信頼モデルを開発するための調査は価値があります。
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.
インターネットコミュニティへの繰り返しの課題は、グローバルなインターネットに存在する無数のセキュリティコンテキストに適した主要な管理を設計、実装、および展開する方法です。Unicast Key Managementの現在の作業のほとんどは、既存の作業の多くが企業または軍事の「トップダウン」運用モデルによって推進されているため、階層的信頼モデルに焦点を当てています。
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.
近年、ある程度の進歩がありましたが、スケーラブルなマルチキャストキー管理は解決された問題ではありません。スケーラブルなマルチキャストキー管理への既存のアプローチは、展開可能な技術ソリューションを考え出すために、問題範囲に大きな制約を追加します。スケーラブルなマルチキャストキー管理（つまり、より広い適用性と制約が少ない）に対するより一般的なアプローチを持つことで、インターネットの機能が向上します。
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は、分散コンピューティングに関する重要かつ広く成功した研究プロジェクトでした。Project Athenaは、キャンパス環境で今日大きな展開を行っているKerberos [RFC-1510]セキュリティシステムを開発しました。ただし、リアルム間のケルベロスは、単一のリアルム・ケルベロスほど広く成功したことでも、広く展開されていないことも認識されていません。スケーラブルなドメイン間ユーザー認証の必要性は、アドホックコンピューティングとモバイルコンピューティングがより広く展開されるため、ますます深刻になります。したがって、モバイル、アドホック、および非階層間のドメイン間認証のためのスケーラブルなメカニズムの作業は非常に役立ちます。
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の提案は、未解決の展開の課題が重要な重要な研究製品の例です。以前に大規模なドメイン間のパブリックキーインフラストラクチャを展開せずにS-BGPを広く展開し、ルーティング情報レジストリまたは同様の機関でルート広告ポリシーの施行を集中化することなく、どのように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）攻撃をほとんど無視してきました。このような攻撃はまれであり、防御するのが難しいため、これは一度に適切でした。ただし、敵対的なソフトウェア（ウイルス、ワームなど）の最近の傾向の1つは、感染した宿主を「ゾンビ」に変える機能の組み込みです。このようなゾンビは、一部の被害者マシンへの分散型サービス拒否攻撃を取り付けるためにリモートで制御できます。多くの場合、システムの承認されたオペレーターは、システムの一部またはすべてがゾンビになっていることを認識していません。グローバルなインターネットにおける非自明な数のゾンビの存在は現在風土病であるように思われ、分散されたサービス拒否攻撃をはるかに大きな懸念にしているようです。したがって、インターネットの脅威モデルは、かなりの数のそのようなゾンビの存在を想定する必要があります。これにより、分散されたサービス拒否攻撃の存在下でプロトコルの設計がインターネットの健康にとって非常に重要になります。このフロント[Savage00]、[MBFIPS01]でいくつかの作業が行われていますが、さらに多くの作業が必要です。
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, 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.
現在、分離されたデバイスではなく、ネットワーク全体を管理するための適切なツールはほとんどまたはまったくありません。たとえば、適切なネットワーク管理ツールの欠如は、IPマルチキャストの広範な展開に対する主要な障壁の1つとして引用されています[DioT00、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を実行することなく簡単に見つけられる場合、問題がWebサーバーがダウンしていること、ネットワークが分割されたことがあるかどうかが役立ちます。パスに沿って激しい混雑があったこと、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 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を10年以上追加することに伴う集中的な研究開発作業がありました[RFC-1633、RFC-2474、RFC-3260、RFC-2205、RFC-2210]が、まだDONはしません'インターネットにエンドツーエンドの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の需要を鈍らせた要因の1つは、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パケットの最良のフォワーディングを提供します。このプロパティは、グローバルなインターネットの現在のスケーラビリティへの重要な貢献者であり、ドメイン間サービス品質（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サポートを提供するネットワークに、重要で簡単に搾取されたサービス拒否の脆弱性が生まれます。これにより、ネットワークオペレーターはドメイン間のQOをサポートすることを控えることができました。インターネットは、QoSへの代替アプローチ、特にそのような脆弱性を生み出さず、エンドツーエンド[RFC-2990]を展開できるアプローチに関する追加の研究から恩恵を受けるでしょう。
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.
また、現在のビジネスモデルは、大部分がドメイン間QOと一致していません。これは、ラインレートでトラフィックを転送しながら、希望するトラフィックの送信者のアイデンティティを認証することは非現実的または不可能であるためです。そのような能力がなければ、ネットワークオペレーターがその優先サービスを提供することに関連するコストを請求または回収する方法は不明です。したがって、ドメイン間の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.
トラフィックの全体的なサービスの質は、ルーターでのスケジューリングおよびキュー管理メカニズムによって部分的に決定されます。うまく機能する多くの既存のメカニズム（例：赤）がありますが、改善されたアクティブキューイング戦略が考案される可能性があります。IPルーターの実装コストを削減したメカニズムは、たとえばアクティブキュー管理の展開を増やすのに役立つ可能性があります。
3.7. Congestion Control.
3.7. 混雑制御。
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.
これらの問題のいくつかは、レイヤー間のコミュニケーションの増加の潜在的なコストと利点に関する困難な基本的な質問を提起します。ルーティング、リンクレイヤー、または他のトランスポートレベルの接続からヒントやその他の情報を受け取るのに役立ちますか？もしそうなら、多様な環境で堅牢な操作のコストはいくらですか？ルーターの輻輳制御メカニズムの場合、アクティブキュー管理と明示的な混雑通知は一般にまだ展開されておらず、この分野ではさまざまな成熟状態でさまざまな提案があります。同時に、キュー管理メカニズムとネットワーク内の他の要因との相互作用についてまだ理解していないことが多くあります。ルーターベースの混雑制御メカニズムは、分散型サービス攻撃やフラッシュクラウドなどの凝集渋滞を検出および応答するためにも必要です。
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.
電子メールをアプリケーションの例として取得すると、スパムの問題を理解すること、およびスパムの効果を軽減するためのツールとテクニックの調査に関する調査が必要です。]。「SPAM」は、さまざまな種類の不要なバルクメールの範囲の一般的な用語であり、多くのタイプの送信者、コンテンツ、トラフィック生成テクニックがあります。スパムの制御の一部として、その多くの異なる特性と互いに相互作用をよりよく理解する必要があります。
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、テネックスで、さまざまなインターネットテクノロジー（例：TCP/IPV4、RSVP、IPv6、IPセキュリティなど）の自由に分散できる実装の開発に歴史的に資金提供を受けてきました。）。経験により、新しいテクノロジーの展開を速める良い方法は、商業製品と非営利プロトタイプに組み込むことができる、邪魔されていない自由に分散できるプロトタイプを提供することであることが示されています。日本のワイドプロジェクトは、主に4.4 BSDとLinuxのIPv6実装に焦点を当てた、そのような作業にも資金を提供しています。[広い]研究プロジェクトチームが結果として得られるソフトウェアの実装を商業用および非営利の両方の使用で自由に利用できるようにすると、ネットワーキングにおける応用研究プロジェクトは成功の可能性を高めると考えています。ここでの成功の例には、4.x BSDオペレーティングシステム[MBKQ96]へのTCP/IPv4統合のDARPA資金、ESP/AH設計のDARPA/USN資金、および4.4 BSD [ATK96]への統合、および個別のDARPA/USNへの資金提供が含まれます。自由に配布可能なIPv6プロトタイプの幅広い資金[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.
何らかの形でこの文書に直接貢献した人々には、ラン・アトキンソン、ガイ・アルメス、ロブ・オーストイン、ヴィント・ケルフ、ジョン・クロウクロフト、サリー・フロイド、ジェームズ・ケンプフ、ジョー・マッカー、クレイグ・パートリッジ、ヴァーン・パクソン、ジュエルゲン・シェーンワエルダー、マイケセントジョンズ。
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.
また、この文書の以前のドラフトに関するフィードバックについて、キム・クラフィー、デイブ・クロッカー、マイケル・エダー、エリック・フライシュマン、アンドレイ・ガルトフ、スティーブン・ケント、J.P。マーティン・フラティン、ヒラリー・オルマンにも感謝しています。
We have also drawn from the following reports: [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/".
[ASRG] IRTFの反スパム研究グループ（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. Atkinson et al。、「4.4 BSDにおけるIPv6の実装」、Usenix 1996年次技術会議の議事録、USENIX Association、Berkeley、CA、USA。1996年1月。URLhttp://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.ベルマン、「ダイナミックプログラミング」、プリンストン大学出版局、プリンストン、ニュージャージー州、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、「インターネット測定、シミュレーション、および分析における優先順位と課題」、大規模ネットワーク会議（米国）国立科学財団、米国バージニア州アーリントン。2003年6月10日。URL「http://www.caida.org/outreach/ presentations/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、「インターネットのトップの問題とSysadminsと研究者が助けるためにできること」、2003年10月、Lisa'03での全体講演。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] D. D. Clark、「インターネットの展開 - なぜそれがそんなに時間がかかり、研究ができるのか」、大規模なネットワーキング著名な講義シリーズ、（米国）国立科学財団、バージニア州アーリントン、2002年1月8日。URL：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]コンピューターサイエンスアンドテレコミュニケーション委員会、（米国）国立研究評議会、「革命への資金：コンピューティングリサーチのための政府の支援」、国立アカデミープレス、ワシントンDC、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]重要なインフラ保護委員会、「サイバースペースを保護するための国家戦略」、ホワイトハウス、ワシントンDC、米国。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. Crowcroft、I。Wakeman、Z。Wang、およびD. Sirovica、「レイヤーは有害ですか？」、IEEE Networks、vol。6、第1号、pp 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、et al。、「IPマルチキャストサービスとアーキテクチャの展開の問題」、IEEEネットワーク、2000年1月/2月。
[Deering1988] S. Deering, "Multicast Routing in Internetworks and LANs", ACM Computer Communications Review, Volume 18, Issue 4, August 1988.
[Deering1988] S.ディアリング、「インターネットワークとLANSのマルチキャストルーティング」、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. Dijkstra、「グラフとの接続における2つの問題に関するメモ」、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.フォードJr.およびD.R.Fulkerson、「Flows in Networks」、プリンストン大学出版局、プリンストン、ニュージャージー州、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. Floyd and E. Kohler、「インターネットリサーチには、より良いモデルが必要」、米国ニュージャージー州プリンストンのNetworks（HotNets-I）のホットトピックに関する第1ワークショップの議事録。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 and G. Maguire Jr.、「モバイルインターネットワーキングアーキテクチャの設計と実装」、冬のUSENIX技術会議の議事録、489-500ページ、米国カリフォルニア州バークレー、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]ヨーロッパの研究ネットワーキング - グローバルリーダーシップ、情報協会Technologies、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] van Jacobson、「混雑回避と管理」、ACM Sigcomm 1988 Symposium、ACM Sigcomm、Stanford、CA、1988年8月。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] William Jackson、「米国は安全なインターネットプロトコルにR＆Dに資金を供給すべきだ、Clarkeは言う」、政府コンピューターニュース、2002年10月31日。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] Hans Kruse、「分散プロトコル開発の落とし穴：ネットワーク操作とアプリケーションプロトコル間の意図しない相互作用」、2000年3月、米国テネシー州ナッシュビルの電気通信システム設計に関する第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. Kent、C。Lynn、J。Mikkelson、およびK. Seo、「Secure Border Gateway Protocol（S-BGP）」、ISOCネットワークおよび分散システムセキュリティSymposium、インターネット協会、RESTON、VA、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.ドロム、「名前の中にあるもの：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]ラトゥル・マハジャン、スティーブン・M・ベロヴィン、サリー・フロイド、ジョン・イオンニディス、ヴァーン・パクソン、スコット・シェンカー、「ネットワーク内の高帯域幅の集合体を制御」、ACM Computer Communications Review、vol。32、No。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。Bostic、M。Karels、およびJ. Quarterman、「4.4 BSDオペレーティングシステムの設計と実装」、Addison-Wesley、Reading、MA、1996。
[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. Mao、R。Govindan、G。Varghese、＆R。Katz、「ルートフラップ減衰はインターネットルーティングのコンバージェンスを悪化させます」、ACM Sigcomm 2002、ACM、Pittsburgh、Pa、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ワークショップ、国立科学財団、コンピューターおよび情報科学＆エンジニアリング局、2002年10月、米国バージニア州アーリントンの高度なネットワーキングインフラストラクチャおよび研究部門。.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主任研究者会議、米国バージニア州アーリントンの国立科学財団。2003年1月9〜10日、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] D. E. Atkins、et al。、「CyberInfrastructureによる科学と工学の革命」、Cyberinfrastructureに関するNSFアドバイザリーパネルのレポート、2003年1月。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]ネットワーキングにおける基本的な研究に関する国立科学財団ワークショップの報告。2003年4月24〜25日。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".
[Floyd] S. Floyd、「インターネットに関する研究質問に関する論文」、Webページ、ICSIインターネット研究センター（ICIR）、Berkeley、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] Kohl、J。およびC. Neuman、「The Kerberos Network Authentication Service（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] Braden、R.、Clark、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。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC-2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC-2154] Murphy、S.、Badger、M.、およびB. Wellington、「Digital Signatures with Digital Signatures」、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] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、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] Corson、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] Huston、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] Huston、G。、「インターネット内のドメイン間ルーティングに関する解説」、RFC 3221、2001年12月。
[RFC-3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC-3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、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、「ネットワークアドレス翻訳全体の一方的な自己アドレス固定（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[RFC-3467] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, February 2003.
[RFC-3467]クレンシン、J。、「ドメイン名システム（DNS）の役割」、RFC 3467、2003年2月。
[RFC-3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003.
[RFC-3535] Schoenwaelder、J。、「2002年のIABネットワーク管理ワークショップの概要」、RFC 3535、2003年5月。
[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] Eder、M.、Chaskar、H。、およびS. Nag、「IPネットワークのサービス品質（QOS）に関するサービス管理研究グループ（SMRG）からの考慮事項」、RFC 3387、2002年9月。
[RIPE] RIPE (Reseaux IP Europeens), Amsterdam, NL. URL "http://www.ripe.net/ripe/".
[熟した]熟した（Reseaux Ip Europeens）、Amsterdam、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] Savage、S.、Wetherall、D.、Karlink、A。R.、およびAnderson、T。、「IP Tracebackの実践的なサポート」、2000 ACM Sigcomm Conference、ACM Sigcomm、Stockholm、SE、pp。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] J. I. Schiller、「インターセプトテクノロジー：良い、悪い、ugい！」、28回目のNanog Meeting、North American Network Operators Group（Nanog）、Ann Arbor、MI、USA、2003年：//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. SharmaおよびR. Malpani、「IPマルチキャストオペレーショナルネットワーク管理：設計、課題、および経験」、IEEE Network、Vol。17、No。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. Spring、R。Mahajan、およびT. Anderson、「パスインフレの原因の定量化」、ACM Sigcomm 2003、ACM、Karlsruhe、ドイツ、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] Walter Willinger and John Doyle、「堅牢性とインターネット：デザインと進化」、未発表/プレップリント、2002年3月1日、url "http://netlab.caltech.edu/internet/"。
[WIDE] WIDE Project, Japan. URL "http://www.wide.ad.jp/".
[ワイド]ワイドプロジェクト、日本。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
バーナード・アボバ・ハラルド・アルベスランド（IETFチェア）ロブ・オーストイン・レスリー・ダイグル（IABチェア）パトリック・ファルトロム・サリー・フロイド・マーク・ハンドリー・ボブ・ヒンデン・ホストン（IABエグゼクティブディレクター）ジュン・イチーロ・イトジュン・イトジュン・ハギノ・エリック・エリック・レスカ・レ・レスニック・ジョナサン・ローズ・ローズ・ローズ・ローズ・ローズ・ローズ
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.
文書の編集者の1人であるRan Atkinsonは、2002年11月にこのドキュメントが最初に作成された当時のIABメンバーであり、IRTF議長であるVern Paxsonが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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。