RFC1752 日本語訳
1752 The Recommendation for the IP Next Generation Protocol. S.Bradner, A. Mankin. January 1995. (Format: TXT=127784 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Bradner
Request for Comments: 1752 Harvard University
Category: Standards Track A. Mankin
ISI
January 1995
コメントを求めるワーキンググループS.ブラドナーの要求をネットワークでつないでください: 1752年のハーバード大学カテゴリ: 標準化過程A.マンキンISI1995年1月
The Recommendation for the IP Next Generation Protocol
IP次世代プロトコルのための推薦
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. This recommendation was accepted by the Internet Engineering Steering Group (IESG).
このドキュメントは何がインターネットプロトコルの最新版を取り替えるのに使用されるべきであるかにおけるIPng Areaディレクターの推薦を提示します。 この推薦はインターネットEngineering Steering Group(IESG)によって受け入れられました。
Table of Contents
目次
1. Summary. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . 4
3. A Direction for IPng . . . . . . . . . . . . . . . . . . 5
4. IPng Area. . . . . . . . . . . . . . . . . . . . . . . . 6
5. ALE Working Group. . . . . . . . . . . . . . . . . . . . 6
5.1 ALE Projections. . . . . . . . . . . . . . . . . . . . . 7
5.2 Routing Table Size . . . . . . . . . . . . . . . . . . . 7
5.3 Address Assignment Policy Recommendations. . . . . . . . 8
6. IPng Technical Requirements. . . . . . . . . . . . . . . 8
6.1 The IPng Technical Criteria document . . . . . . . . . . 9
7. IPng Proposals . . . . . . . . . . . . . . . . . . . . . 11
7.1 CATNIP. . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2 SIPP. . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3 TUBA. . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. IPng Proposal Reviews. . . . . . . . . . . . . . . . . . 13
8.1 CATNIP Reviews . . . . . . . . . . . . . . . . . . . . . 14
8.2 SIPP Reviews . . . . . . . . . . . . . . . . . . . . . . 15
8.3 TUBA Reviews . . . . . . . . . . . . . . . . . . . . . . 16
8.4 Summary of Proposal Reviews. . . . . . . . . . . . . . . 17
9. A Revised Proposal . . . . . . . . . . . . . . . . . . . 17
10 Assumptions . . . . . . . . . . . . . . . . . . . . . . 18
10.1 Criteria Document and Timing of Recommendation . . . . . 18
1. 概要。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . 4 3。 IPng. . . . . . . . . . . . . . . . . . 5 4のための指示。 IPng領域。 . . . . . . . . . . . . . . . . . . . . . . . 6 5. エール作業部会。 . . . . . . . . . . . . . . . . . . . 6 5.1 エール映像。 . . . . . . . . . . . . . . . . . . . . 7 5.2 ルート設定テーブル・サイズ. . . . . . . . . . . . . . . . . . . 7 5.3は課題政策提言を記述します。 . . . . . . . 8 6. IPng技術的要求事項。 . . . . . . . . . . . . . . 8 6.1 IPng Technical Criteriaは.9 7を記録します。 IPng提案. . . . . . . . . . . . . . . . . . . . . 11 7.1キャットニップ。 . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2 SIPP。 . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3チューバ。 . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. IPng提案は論評します。 . . . . . . . . . . . . . . . . . 13 8.1 提案のキャットニップレビュー. . . . . . . . . . . . . . . . . . . . . 14 8.2SIPPレビュー. . . . . . . . . . . . . . . . . . . . . . 15 8.3チューバレビュー. . . . . . . . . . . . . . . . . . . . . . 16 8.4概要は再検討されます。 . . . . . . . . . . . . . . 17 9. 推薦. . . . . 18の改訂された提案. . . . . . . . . . . . . . . . . . . 17 10仮定. . . . . . . . . . . . . . . . . . . . . . 18 10.1評価基準ドキュメントとタイミング
Bradner & Mankin [Page 1] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[1ページ]RFC1752推薦
10.2 Address Length . . . . . . . . . . . . . . . . . . . . . 19
11. IPng Recommendation. . . . . . . . . . . . . . . . . . . 19
11.1 IPng Criteria Document and IPng. . . . . . . . . . . . . 20
11.2 IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. IPv6 Overview . . . . . . . . . . . . . . . . . . . . . 21
12.1 IPv6 Header Format . . . . . . . . . . . . . . . . . . . 24
12.2 Extension Headers. . . . . . . . . . . . . . . . . . . . 25
12.2.1 Hop-by-Hop Option Header . . . . . . . . . . . . . . . . 25
12.2.2 IPv6 Header Options. . . . . . . . . . . . . . . . . . . 26
12.2.3 Routing Header . . . . . . . . . . . . . . . . . . . . . 27
12.2.4 Fragment Header. . . . . . . . . . . . . . . . . . . . . 28
12.2.5 Authentication Header. . . . . . . . . . . . . . . . . . 29
12.2.6 Privacy Header . . . . . . . . . . . . . . . . . . . . . 30
12.2.7 End-to-End Option Header . . . . . . . . . . . . . . . . 32
13. IPng Working Group . . . . . . . . . . . . . . . . . . . 32
14. IPng Reviewer . . . . . . . . . . . . . . . . . . . . . 33
15. Address Autoconfiguration. . . . . . . . . . . . . . . . 33
16. Transition . . . . . . . . . . . . . . . . . . . . . . . 34
16.1 Transition - Short Term. . . . . . . . . . . . . . . . . 35
16.2 Transition - Long Term . . . . . . . . . . . . . . . . . 36
17. Other Address Families . . . . . . . . . . . . . . . . . 37
18. Impact on Other IETF Standards . . . . . . . . . . . . . 38
19. Impact on non-IETF standards and on products . . . . . . 39
20. APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 39
21. Future of the IPng Area and Working Groups . . . . . . . 40
22. Security Considerations. . . . . . . . . . . . . . . . . 40
23. Authors' Addresses . . . . . . . . . . . . . . . . . . . 43
10.2は長さ. . . . . . . . . . . . . . . . . . . . . 19 11を記述します。 IPng推薦。 . . . . . . . . . . . . . . . . . . 19 11.1のIPng評価基準ドキュメントとIPng。 . . . . . . . . . . . . 20 11.2 IPv6。 . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. IPv6概観. . . . . . . . . . . . . . . . . . . . . 21 12.1IPv6ヘッダー形式. . . . . . . . . . . . . . . . . . . 24 12.2拡張ヘッダー。 . . . . . . . . . . . . . . . . . . . 25 12.2.1 ホップで、オプションヘッダー. . . . . . . . . . . . . . . . 25 12.2.2のIPv6ヘッダーオプションを飛び越してください。 . . . . . . . . . . . . . . . . . . 26 12.2.3 ルート設定ヘッダー. . . . . . . . . . . . . . . . . . . . . 27 12.2.4はヘッダーを断片化します。 . . . . . . . . . . . . . . . . . . . . 28 12.2.5 認証ヘッダー。 . . . . . . . . . . . . . . . . . 29 12.2.6 プライバシーヘッダー.30 12.2.7終わりから終わりへのオプションヘッダー. . . . . . . . . . . . . . . . 32 13。 IPng作業部会. . . . . . . . . . . . . . . . . . . 32 14。 IPng評論家. . . . . . . . . . . . . . . . . . . . . 33 15。 自動構成を記述してください。 . . . . . . . . . . . . . . . 33 16. 変遷. . . . . . . . . . . . . . . . . . . . . . . 34 16.1変遷--短い期間。 . . . . . . . . . . . . . . . . 35 16.2 変遷--長期. . . . . . . . . . . . . . . . . 36 17。 他のアドレス家族. . . . . . . . . . . . . . . . . 37 18。 他のIETF規格. . . . . . . . . . . . . 38 19で影響を与えてください。 非IETF規格の上と、そして、製品. . . . . . 39 20の上に影響を与えてください。 API. . . . . . . . . . . . . . . . . . . . . . . . . . 39 21。 IPng領域とワーキンググループ. . . . . . . 40 22の未来。 セキュリティ問題。 . . . . . . . . . . . . . . . . 40 23. 作者のアドレス. . . . . . . . . . . . . . . . . . . 43
Appendix A Summary of Recommendations . . . . . . . . . . . . . 44 Appendix B IPng Area Directorate. . . . . . . . . . . . . . . . 45 Appendix C Documents Referred to the IPng Working Groups. . . . 46 Appendix D IPng Proposal Overviews. . . . . . . . . . . . . . . 46 Appendix E RFC 1550 White Papers. . . . . . . . . . . . . . . . 47 Appendix F Additional References. . . . . . . . . . . . . . . . 48 Appendix G Acknowledgments. . . . . . . . . . . . . . . . . . . 52
推薦. . . . . . . . . . . . . 44付録B IPng領域の管理職の付録A概要。 . . . . . . . . . . . . . . . 45 付録CドキュメントはIPngワーキンググループについて言及しました。 . . . 46 付録D IPng提案概観。 . . . . . . . . . . . . . . 46 RFC1550付録Eの白書。 . . . . . . . . . . . . . . . 47 付録のF追加参照。 . . . . . . . . . . . . . . . 48 付録G承認。 . . . . . . . . . . . . . . . . . . 52
1. Summary
1. 概要
The IETF started its effort to select a successor to IPv4 in late 1990 when projections indicated that the Internet address space would become an increasingly limiting resource. Several parallel efforts then started exploring ways to resolve these address limitations while at the same time providing additional functionality. The IETF formed the IPng Area in late 1993 to investigate the various proposals and recommend how to proceed. We developed an IPng technical criteria document and evaluated the various proposals against it. All were found wanting to some degree. After this evaluation, a revised proposal was offered by one of the working
IETFは1990年に映像がインターネットアドレス空間がますます制限しているリソースになるのを示した後半IPv4の後継者を選ぶための努力を始めました。 そして、いくつかの平行な努力が同時に追加機能性を提供する間にこれらのアドレス制限を決議する方法を探り始めました。 IETFは、1993年後半に様々な提案を調査して、どう続くかを推薦するためにIPng Areaを形成しました。 私たちは、IPngの技術的な評価基準ドキュメントを開発して、それに対して様々な提案を評価しました。 すべてがある程度足りないのがわかりました。 この評価の後に、働きのもので改訂された提案を出しました。
Bradner & Mankin [Page 2] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[2ページ]RFC1752推薦
groups that resolved many of the problems in the previous proposals. The IPng Area Directors recommend that the IETF designate this revised proposal as the IPng and focus its energy on bringing a set of documents defining the IPng to Proposed Standard status with all deliberate speed.
前の提案における問題の多くを解決したグループ。 IPng Areaディレクターは、すべてのゆっくりとした速度でIPngを定義する1セットのドキュメントをProposed Standard状態に持って来るときIETFがIPngと焦点としてのこの改訂された提案をエネルギーに指定することを勧めます。
This protocol recommendation includes a simplified header with a hierarchical address structure that permits rigorous route aggregation and is also large enough to meet the needs of the Internet for the foreseeable future. The protocol also includes packet-level authentication and encryption along with plug and play autoconfiguration. The design changes the way IP header options are encoded to increase the flexibility of introducing new options in the future while improving performance. It also includes the ability to label traffic flows.
このプロトコル推薦も、厳しいルート集合を可能にする階層的なアドレス構造で簡易型のヘッダーを含んで、また、予見できる未来をインターネットの需要を満たすことができるくらい大きいです。 また、プロトコルはプラグアンドプレイ自動構成に伴うパケット・レベル認証と暗号化を含んでいます。 デザインはIPヘッダーオプションが将来性能を向上させている間、新しいオプションを紹介する柔軟性を高めるためにコード化される方法を変えます。 また、それは交通の流れをラベルする能力を含んでいます。
Specific recommendations include:
特定の推薦は:
* current address assignment policies are adequate
* there is no current need to reclaim underutilized assigned network
numbers
* there is no current need to renumber major portions of the Internet
* CIDR-style assignments of parts of unassigned Class A address space
should be considered
* "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)"
[Deering94b] be adopted as the basis for IPng
* the documents listed in Appendix C be the foundation of the IPng
effort
* an IPng Working Group be formed, chaired by Steve Deering and Ross
Callon
* Robert Hinden be the document editor for the IPng effort
* an IPng Reviewer be appointed and that Dave Clark be the reviewer
* an Address Autoconfiguration Working Group be formed, chaired by
Dave Katz and Sue Thomson
* an IPng Transition Working Group be formed, chaired by Bob Gilligan
and TBA
* the Transition and Coexistence Including Testing Working Group be
chartered
* recommendations about the use of non-IPv6 addresses in IPv6
environments and IPv6 addresses in non-IPv6 environments be
developed
* the IESG commission a review of all IETF standards documents for
IPng implications
* the IESG task current IETF working groups to take IPng into account
* the IESG charter new working groups where needed to revise old
standards documents
* Informational RFCs be solicited or developed describing a few
specific IPng APIs
* 現在のアドレス課題方針はそこの適切な*による*そこでunderutilized割り当てられたネットワーク・ナンバーを取り戻すどんな現在の必要性も*「簡単なインターネットプロトコルプラス(SIPP)仕様」であると割り当てられなかったClass Aアドレス空間の部品のインターネット*CIDR-スタイル課題の主要部に番号を付け替えさせるどんな現在の必要性も考えるべきでないということでないということであるということです。 (128ビットのver)「Deering94b、IPngの努力*の形成されて、スティーブ・デアリングによってまとめられたIPng作業部会とロスCallon*の基礎がロバートHindenであったならIPngの努力*のためのドキュメントエディタがIPng Reviewerであったなら書類がAppendix Cに記載したIPng*の基礎として採用されて、任命されてください、デーブ・クラークが評論家*Address Autoconfiguration作業部会であることが形成され、デーヴ・キャッツとスー・トムソン*によるIPng Transition作業部会をまとめた、形成されてください、」; *開発されていて、非IPv6の使用に関する貸し切りの*推薦が非IPv6環境でIPv6環境とIPv6アドレスのアドレスであったならボブ・ギリガンとTBA*のTransitionとCoexistence Including Testing作業部会によってまとめられて、IESGはすべてのレビューを任命します; いくつかの特定のIPngについて説明しながら請求されるか開発されていて、古い規格文書*の情報のRFCsを改訂するのが必要であるところで*IESGがアカウント*へのIPngにIESGを連れて行くために現在のIETFワーキンググループに仕事を課すというIPng含意のためのIETF規格文書は新しいワーキンググループをチャーターします。API
Bradner & Mankin [Page 3] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[3ページ]RFC1752推薦
* the IPng Area and Area Directorate continue until main documents
are offered as Proposed Standards in late 1994
* support for the Authentication Header be required
* support for a specific authentication algorithm be required
* support for the Privacy Header be required
* support for a specific privacy algorithm be required
* an "IPng framework for firewalls" be developed
* IPng AreaとArea Directorateは開発されていて、必要な*が特定の認証アルゴリズムのサポートであったなら必要な*がPrivacy Headerのサポートであったなら必要な*が特定のプライバシーアルゴリズムのサポートであったなら必要な*が「ファイアウォールへのIPng枠組み」であったならProposed Standardsとして1994年のAuthentication Headerの遅い*サポートで主なドキュメントを提供するまで続きます。
2. Background
2. バックグラウンド
Even the most farseeing of the developers of TCP/IP in the early 1980s did not imagine the dilemma of scale that the Internet faces today. 1987 estimates projected a need to address as many as 100,000 networks at some vague point in the future. [Callon87] We will reach that mark by 1996. There are many realistic projections of many millions of interconnected networks in the not too distant future. [Vecchi94, Taylor94]
1980年代前半のTCP/IPの開発者で最も明敏さえインターネットが今日直面しているスケールのジレンマを想像しませんでした。 1987の見積りが将来何らかのあいまいなポイントの最大10万のネットワークに演説する必要性を映し出しました。 [Callon87] 私たちは1996年までにそのマークに達するでしょう。 何百万もの相互接続ネットワークの多くの現実的な予想があまり遠くない将来にあります。 [Vecchi94、Taylor94]
Further, even though the current 32 bit IPv4 address structure can enumerate over 4 billion hosts on as many as 16.7 million networks, the actual address assignment efficiency is far less than that, even on a theoretical basis. [Huitema94] This inefficiency is exacerbated by the granularity of assignments using Class A, B and C addresses.
さらに、32ビットの現在のIPv4アドレス構造は最大1670万のネットワークの40億人以上のホストを数え上げることができますが、絶対番地課題効率が遠くに理論的基礎にさえあります。 [Huitema94] この非能率は、課題の粒状によってClass A、B、およびCアドレスを使用することで悪化させられます。
In August 1990 during the Vancouver IETF meeting, Frank Solensky, Phill Gross and Sue Hares projected that the current rate of assignment would exhaust the Class B space by March of 1994.
バンクーバーのIETFミーティングの間の1990年8月に、フランクSolensky、フィルGross、およびスーHaresは、Class Bスペースが1994年3月までに課題の成り行き相場でくたくたになると予測しました。
The then obvious remedy of assigning multiple Class C addresses in place of Class B addresses introduced its own problem by further expanding the size of the routing tables in the backbone routers already growing at an alarming rate.
Class Bアドレスに代わって複数のClass Cにアドレスを割り当てる当時の明白な療法は、さらに既に驚くべき率で成長する背骨ルータにおける、経路指定テーブルのサイズを広げることによって、それ自身の問題を紹介しました。
We faced the dilemma of choosing between accepting either limiting the rate of growth and ultimate size of the Internet, or disrupting the network by changing to new techniques or technologies.
私たちは成長のレートとインターネットの究極のサイズを制限するか、または新しいやり方か技術に変化することによってネットワークを混乱させながら受諾を選ぶジレンマに直面していました。
The IETF formed the Routing and Addressing (ROAD) group in November 1991 at the Santa Fe IETF meeting to explore this dilemma and guide the IETF on the issues. The ROAD group reported their work in March 1992 at the San Diego IETF meeting. [Gross92] The impact of the recommendations ranged from "immediate" to "long term" and included adopting the CIDR route aggregation proposal [Fuller93] for reducing the rate of routing table growth and recommending a call for proposals "to form working groups to explore separate approaches for bigger Internet addresses."
IETFは1991年11月にこのジレンマについて調査して、問題でIETFを誘導するサンタフェのIETFミーティングでルート設定とAddressing(ROAD)グループを結成しました。 ROADグループは1992年3月にサンディエゴIETFミーティングで彼らの仕事を報告しました。 [Gross92] 推薦の影響は、「即座」から「長期」まで及んで、経路指定テーブルの成長のレートを低下させるために、CIDRルート集合提案[Fuller93]を採用して、「より大きいインターネット・アドレスのための別々のアプローチについて調査するためにワーキンググループを形成する」という提案のために呼び出しを推薦するのを含んでいました。
Bradner & Mankin [Page 4] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[4ページ]RFC1752推薦
In the late spring of 1992 the IAB issued "IP version 7" [IAB92], concurring in the ROAD group's endorsement of CIDR and also recommending "an immediate IETF effort to prepare a detailed and organizational plan for using CLNP as the basis for IPv7." After spirited discussion, the IETF decided to reject the IAB's recommendation and issue the call for proposals recommended by the ROAD group. This call was issued in July 1992 at the Boston IETF meeting and a number of working groups were formed in response
IABが「ROADグループのCIDRの裏書きに同意して、また「IPv7の基礎としてCLNPを使用するために詳細で組織的なプランを準備するための即座のIETFの努力」を推薦するIPバージョン7インチ[IAB92]」を発行した1992年の晩春に 活発な議論の後に、IETFは、提案のための呼び出しがROADグループで推薦したIABの推薦と問題を拒絶すると決めました。 この呼び出しは1992年7月にボストンのIETFミーティングで発行されました、そして、多くのワーキンググループが応答で形成されました。
During the July 1993 Amsterdam IETF meeting an IPng (IP Next Generation) Decision Process (ipdecide) BOF was held. This BOF "was intended to help re-focus attention on the very important topic of making a decision between the candidates for IPng. The BOF focused on the issues of who should take the lead in making the recommendation to the community and what criteria should be used to reach the recommendation." [Carpen93]
1993年7月のアムステルダムIETFミーティングの間、IPng(IP Next Generation)決定Process(ipdecide)BOFは持たれていました。 このBOFは「IPngの候補の間で決定する非常に重要な話題に注意の焦点を再び合わせるのを助けることを意図しました」。 「BOFはだれが推薦状を共同体にする際にリードするべきであるか、そして、どんな評価基準が推薦に達するのに使用されるべきであるかに関する問題に焦点を合わせました。」 [Carpen93]
3. A Direction for IPng
3. IPngのための指示
In September 1993 Phill Gross, chair of the IESG issued "A Direction for IPng". [Gross94] In this memo he summarized the results of the ipdecide BOF and open IESG plenary in Amsterdam.
1993年9月のフィルGrossのときに、IESGのいすは「IPngのための指示」を発行しました。 [Gross94] このメモでは、彼はアムステルダムで絶対的なipdecide BOFと開いているIESGの結果をまとめました。
* The IETF needs to move toward closure on IPng.
* The IESG has the responsibility for developing an IPng
recommendation for the Internet community.
* The procedures of the recommendation-making process should be open
and published well in advance by the IESG.
* As part of this process, the IPng WGs may be given new milestones
and other guidance to aid the IESG.
* There should be ample opportunity for community comment prior to
final IESG recommendation.
* IETFは、IPngで閉鎖に近づく必要があります。 * IESGには、インターネットコミュニティのためのIPng推薦を開発することへの責任があります。 * 推薦状をする過程の手順は、開いてよく早くIESGによって広められるはずです。 * この過程の一部として、IESGを支援するために新しい重大事件と他の指導をIPng WGsに与えるかもしれません。 * 最終的なIESG推薦の前に、共同体コメントの十分な機会があるべきです。
The memo also announced "a temporary, ad hoc, 'area' to deal specifically with IPng issues." Phill asked two of the current IESG members, Allison Mankin (Transport Services Area) and Scott Bradner (Operational Requirements Area), to act as Directors for the new area. The Area Directors were given a specific charge on how to investigate the various IPng proposals and how to base their recommendation to the IETF. It was also requested that a specific recommendation be made.
また、メモは「特にIPng問題に対処する一時的で、臨時の'領域'」を発表しました。 フィルは、新しい領域へのディレクターとして務めるように2人の現在のIESGメンバーアリソン・マンキン(輸送Services Area)とスコット・ブラドナー(操作上のRequirements Area)に頼みました。 どのように様々なIPng提案を調査するか、そして、どのように彼らの推薦をIETFに基礎づけるかの特定の料金をAreaディレクターに与えました。 また、特定の推薦状をするよう要求されました。
* Establish an IPng directorate.
* Ensure that a completely open process is followed.
* Develop an understanding of the level of urgency and the time
constraints imposed by the rate of address assignment and rate of
growth in the routing tables.
* Recommend the adoption of assignment policy changes if warranted.
* IPng管理職を確立してください。 * 完全に開いている過程が従われているのを確実にしてください。 * 経路指定テーブルで緊急のレベルの理解とアドレス課題と成長率のレートによって課された時間規制を育んでください。 * 保証されるなら、課題政策変更の採用を推薦してください。
Bradner & Mankin [Page 5] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[5ページ]RFC1752推薦
* Define the scope of the IPng effort based on the understanding of
the time constraints.
* Develop a clear and concise set of technical requirements and
decision criteria for IPng.
* Develop a recommendation about which of the current IPng candidates
to accept, if any.
* 時間規制の理解に基づくIPngの努力の範囲を定義してください。 * IPngのために技術的要求事項と明確で簡潔な決定基準を開発してください。 * もしあれば現在のIPng候補のどれを受け入れたらよいかに関して推薦を開発してください。
4. IPng Area
4. IPng領域
After the IPng Area was formed, we recruited a directorate. (Appendix B) The members of the directorate were chosen both for their general and specific technical expertise. The individuals were then asked to have their management authorize this participation in the process and confirm that they understood the IETF process.
IPng Areaが形成された後に、私たちは管理職を募集しました。 (付録B) 管理職のメンバーはともに彼らの一般的で特定の技術的専門知識に選ばれました。 そして、個人は、彼らの経営者側に過程へのこの参加を認可させて、彼らがIETFの過程を理解していると確認するように頼まれました。
We took great care to ensure the inclusion of a wide spectrum of knowledge. The directors are experts in security, routing, the needs of large users, end system manufacturers, Unix and non-Unix platforms, router manufacturers, theoretical researchers, protocol architecture, and the operating regional, national, and international networks. Additionally, several members of the directorate were deeply involved in each of the IPng proposal working groups.
私たちは、知識の広いスペクトルの包含を確実にするために高度の注意を取りました。 ディレクターはセキュリティ、ルーティング、大きいユーザ、終わりのシステムメーカー、Unixと非unixプラットホーム、ルータメーカー、理論的研究者、プロトコルアーキテクチャ、および操作地方版(国家的、そして、国際的なネットワーク)の必要性の専門家です。 さらに、管理職の数人のメンバーが深くそれぞれのIPng提案ワーキンググループにかかわりました。
The directorate functions as a direction-setting and preliminary review body as requested by the charge to the area. The directorate engages in biweekly conference calls, participates in an internal mailing list and corresponds actively on the Big-Internet mailing list. The directorate held open meetings during the March 1994 Seattle and July 1994 Toronto IETF meetings as well as two additional multi-day retreats. To ensure that the IPng process was as open as possible, we took minutes during these meetings and then published them. Additionally, we placed the archives of the internal IPng mailing list on an anonymous ftp site. (Hsdndev.harvard.edu: pub/ipng.)
管理職は要求された通り方向を設定していて予備の調査機関としてその領域への充電で機能します。 管理職は、隔週の電話会議に従事して、内部のメーリングリストに参加して、Big-インターネットメーリングリストで活発に対応します。 管理職は2つの追加マルチデイ後退と同様に1994年3月のシアトルと1994年7月トロントのIETFミーティングの間、公開の会議を開催しました。 IPngが処理するのを保証するのができるだけ開いていて、私たちは、これらのミーティングの間の何分もかかって、次に、それらを発行しました。 さらに、私たちは内部のIPngメーリングリストのアーカイブをアノニマスFTPサイトに置きました。 (Hsdndev.harvard.edu: パブ/ipng)。
5. ALE Working Group
5. エール作業部会
We needed a reasonable estimate of the time remaining before we exhausted the IPv4 address space in order to determine the scope of the IPng effort. If the time remaining was about the same needed to deploy a replacement, then we would have select the IPng which would only fix the address limitations since we would not have enough time to develop any other features. If more time seemed available, we could consider additional improvements.
私たちは、IPv4アドレス空間がIPng取り組みの範囲を決定するために私たちでくたくたになることのようになる前に残りながら、現代の合理的な見積りを必要としました。 残りがほぼ同じくらいであった時が、交換を配布する必要があったなら、私たちが私たちには、いかなる他の特徴も発生できるくらいの時間がないでしょう、したがって、アドレス制限を修理するだけであるIPngを選択させるその時です。 より多くの時間が利用可能に見えるなら、私たちは追加改良を考えることができるでしょうに。
The IETF formed an Address Lifetime Expectations (ALE) Working Group in 1993 "to develop an estimate for the remaining lifetime of the IPv4 address space based on currently known and available
IETFは、1993年に「現在、知られていて利用可能に基づいてIPv4アドレス空間の残っている生涯のための見積りを発生する」ようにAddress Lifetime Expectations(ALE)作業部会を形成しました。
Bradner & Mankin [Page 6] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[6ページ]RFC1752推薦
technologies." [Solens93a] Tony Li of Cisco Systems and Frank Solensky of FTP Software are the co-chairs. The IETF also charged the working group to consider if developing more stringent address allocation and utilization policies might provide more time for the transition.
「技術。」 シスコシステムズの[Solens93a]トニー・李とFTP SoftwareのフランクSolenskyは共同議長です。 より厳しい状態で展開するなら、また、考えるためにワーキンググループに請求されたIETFは方針が提供するかもしれない配分と利用に変遷のための、より多くの時間を扱います。
5.1 ALE Projections
5.1 エール映像
The ALE Working Group met during the November 1993 Houston, [Solens93b] March 1994 Seattle [Bos93] and July 1994 Toronto [Solens94] IETF meetings. They projected at the Seattle meeting, later confirmed at the Toronto meeting that, using the current allocation statistics, the Internet would exhaust the IPv4 address space between 2005 and 2011.
ALE作業部会は11月1993ヒューストン、1994年の[Solens93b]行進シアトル[Bos93]、7月に1994のトロント[Solens94]のIETFミーティングを満たしました。 彼らは、後でトロントのミーティングで確認されたシアトルのミーティングで現在の配分統計を使用して、IPv4アドレス空間がインターネットで2005と2011にくたくたになると予測しました。
Some members of the ipv4-ale and big-internet mailing lists called into question the reliability of this projection. It has been criticized as both too optimistic and as too pessimistic.
ipv4-エールと大きいインターネットメーリングリストのメンバーの中にはこの映像の信頼性を疑った人もいました。 それはともに楽観的過ぎることとして悲観的過ぎることとして批評されました。
Some people pointed out that this type of projection makes an assumption of no paradigm shifts in IP usage. If someone were to develop a new 'killer application', (for example cable-TV set top boxes.) The resultant rise in the demand for IP addresses could make this an over-estimate of the time available.
人々の中にはこのタイプの映像がIP用法における、パラダイム・シフトがない仮定をすると指摘した人もいました。 だれかが新しい'キラー・アプリケーション'、(例えば、ケーブルテレビセット最高な箱)を開発するつもりであったなら IPアドレスの要求における結果の上昇はこれを空いている現代の過大評価にするかもしれません。
There may also be a problem with the data used to make the projection. The InterNIC allocates IP addresses in large chunks to regional Network Information Centers (NICs) and network providers. The NICs and the providers then re-allocate addresses to their customers. The ALE projections used the InterNIC assignments without regard to the actual rate of assignment of addresses to the end users. They did the projection this way since the accuracy of the data seems quite a bit higher. While using this once-removed data may add a level of over-estimation since it assumes the rate of large block allocation will continue, this may not be the case.
また、映像を作るのに使用されるデータに関する問題があるかもしれません。 InterNICは地方のNetwork Informationセンターズ(NICs)とネットワーク内の提供者に大きい塊におけるIPアドレスを割り当てます。 そして、NICsとプロバイダーは彼らの顧客にアドレスを再割当てします。 ALE映像は関係なしでアドレスの課題対エンドユーザの実際の速度にInterNIC課題を使用しました。 データの精度がかなりのビットより高く見えるので、彼らはこのように映像をしました。 これを使用している間、大きいブロック配分の速度が続くと仮定するので、一度取り除かれたデータは過大評価のレベルを加えるかもしれなくて、これはそうでないかもしれません。
These factors reduce the reliability of the ALE estimates but, in general, they seem to indicate enough time remaining in the IPv4 address space to consider adding features in an IPng besides just expanding the address size even when considering time required for development, testing, and deployment.
これらの要素はALE見積りの信頼性を減少させますが、一般に、それらは、時間が開発、テスト、および展開に必要であると考えるときさえただアドレスサイズを広げること以外にIPngで特徴を加えると考えるためにIPv4アドレス空間に残りながら十分な時間を示すように思えます。
5.2 Routing Table Size
5.2 ルート設定テーブル・サイズ
Another issue in Internet scaling is the increasing size of the routing tables required in the backbone routers. Adopting the CIDR block address assignment and aggregating routes reduced the size of the tables for awhile but they are now expanding again. Providers now
インターネットスケーリングによる別の問題はバックボーンルータで必要である経路指定テーブルの増加するサイズです。 CIDRブロック・アドレス課題を採用して、ルートに集めるのはしばらくテーブルのサイズを減少させましたが、それらは現在、再び広がっています。 現在のプロバイダー
Bradner & Mankin [Page 7] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[7ページ]RFC1752推薦
need to more aggressively advertise their routes only in aggregates. Providers must also advise their new customers to renumber their networks in the best interest of the entire Internet community.
集合だけで、より積極的にそれらのルートの広告を出すのが必要です。 また、プロバイダーは、彼らの新しい顧客が全体のインターネットコミュニティの最も良い利益のためで彼らのネットワークに番号を付け替えさせるようにアドバイスしなければなりません。
The problem of exhausting the IPv4 address space may be moot if this issue is ignored and if routers cannot be found that can keep up with the table size growth. Before implementing CIDR the backbone routing table was growing at a rate about 1.5 times as fast as memory technology.
この問題を無視して、テーブル・サイズの成長について行くことができるルータを見つけることができないなら、IPv4アドレス空間を消耗させるという問題は論争中であるかもしれません。 以前、CIDRがバックボーン経路指定テーブルであると実装するのが速度でメモリ技術のおよそ1.5倍速く成長していました。
We should also note that even though IPng addresses are designed with aggregation in mind switching to IPng will not solve the routing table size problem unless the addresses are assigned rigorously to maximize the affect of such aggregation. This efficient advertising of routes can be maintained since IPng includes address autoconfiguration mechanisms to allow easy renumbering if a customer decides to switch providers. Customers who receive service from more than one provider may limit the ultimate efficiency of any route aggregation. [Rekhter94]
また、私たちは、集合が念頭でIPngに切り替わっていてIPngアドレスが設計されていますが、アドレスがそのような集合の感情を最大にするためにきびしく割り当てられないとそれが経路指定テーブルサイズ問題を解決しないことに注意するべきです。 顧客が、プロバイダーを切り換えると決めるならIPngが簡単な番号を付け替えることを許すためにアドレス自動構成メカニズムを含んでいるので、ルートのこの効率的な広告を維持できます。 1つ以上のプロバイダーからサービスを受ける顧客はどんなルート集合の究極の効率も制限するかもしれません。 [Rekhter94]
5.3 Address Assignment Policy Recommendations
5.3 アドレス課題政策提言
The IESG Chair charged the IPng Area to consider recommending more stringent assignment policies, reclaiming some addresses already assigned, or making a serious effort to renumber significant portions of the Internet. [Gross94]
IESG議長は、より厳しい課題方針を推薦すると考えるためにIPng Areaを請求しました、既にインターネットの重要な部分に番号を付け替えさせるための本格的な対策を割り当てられるか、またはするいくつかのアドレスを取り戻して。 [Gross94]
The IPng Area Directors endorse the current address assignment policies in view of the ALE projections. We do not feel that anyone should take specific efforts to reclaim underutilized addresses already assigned or to renumber forcefully major portions of the Internet. We do however feel that we should all encourage network service providers to assist new customers in renumbering their networks to conform to the provider's CIDR assignments.
IPng AreaディレクターはALE映像から見て現在のアドレス課題方針を是認します。 私たちは、だれでも既に割り当てられたunderutilizedアドレスを取り戻すか、またはインターネットの力強く主要な部分に番号を付け替えさせるために特定の取り組みを取るべきであると感じません。 しかしながら、私たちは、私たちが皆、ネットワークサービスプロバイダーがプロバイダーのCIDR課題に従うために彼らのネットワークに番号を付け替えさせるのに新しい顧客を助けるよう奨励するべきであると感じます。
The ALE Working Group recommends that we consider assigning CIDR-type address blocks out of the unassigned Class A address space. The IPng Area Directors concur with this recommendation.
ALE作業部会は、私たちが、あて先ブロックを割り当てられなかったClass Aアドレス空間からCIDR-タイプに割り当てると考えることを勧めます。 IPng Areaディレクターはこの推薦に同意します。
6. IPng Technical Requirements
6. IPng技術的要求事項
The IESG provided an outline in RFC 1380 [Gross92] of the type of criteria we should use to determine the suitability of an IPng proposal. The IETF further refined this understanding of the appropriate criteria with the recommendations of a Selection Criteria BOF held during the November 1992 IETF meeting in Washington D.C. [Almqu92] We felt we needed to get additional input for determining the requirements and issued a call for white papers. [Bradner93] This
私たちがIPng提案の適合を決定するのに使用するべきである評価基準の1380のRFCタイプ[Gross92]でIESGはアウトラインを提供しました。 IETFはさらにSelection Criteria BOFの推薦が1992年11月のIETFミーティングの間、追加するようになるのを私たちが、感じた必要であったワシントンDC[Almqu92]に保持されている要件を決定するために入力されて、白書のための呼び出しが発行された適切な評価基準のこの理解を洗練しました。 [Bradner93] これ
Bradner & Mankin [Page 8] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[8ページ]RFC1752推薦
call, issued as RFC 1550, intended to reach both inside and outside the traditional IETF constituency to get the broadest possible understanding of the requirements for a data networking protocol with the broadest possible application.
電話をしてください、可能な限り広いアプリケーションによるデータネットワーク・プロトコルのための要件の可能な限り広い理解を得るために選挙民の中と、そして、伝統的なIETF選挙民の外で達することを意図するRFC1550として発行されて。
We received twenty one white papers in response to the RFC 1550 solicitation. ( Appendix E) We received responses from the industries that many feel will be the major providers of data networking services in the future; the cable TV industry [Vecchi94], the cellular industry [Taylor94], and the electric power industry [Skelton94]. In addition, we received papers that dealt with military applications [Adam94, Syming94, Green94], ATM [Brazd94], mobility [Simpson94], accounting [Brown94], routing [Estrin94a, Chiappa94], security [Adam94, Bell94b, Brit94, Green94, Vecchi94, Flei94], large corporate networking [Britt94, Fleisch94], transition [Carpen94a, Heager94], market acceptance [Curran94, Britt94], host implementations [Bound94], as well as a number of other issues. [Bello94a, Clark94, Ghisel94]
私たちはRFC1550懇願に対応して21の白書を受け取りました。 (付録E) 私たちは多くが将来主要なデータネットワークサービスのプロバイダーになるのを感じる産業から応答を受けました。 ケーブルテレビ産業[Vecchi94]、セル産業[Taylor94]、および電気事業[Skelton94]。 さらに、私たちは軍事利用[Adam94、Syming94、Green94]に対処した書類を受け取りました、ATM[Brazd94]、移動性[Simpson94]、会計[Brown94]、ルーティング[Estrin94a、Chiappa94]、セキュリティ[Adam94、Bell94b、Brit94、Green94、Vecchi94、Flei94]、大きい法人のネットワーク[Britt94、Fleisch94]、変遷[Carpen94a、Heager94]、市場承認[Curran94、Britt94]、ホスト導入[Bound94]、他の多くの問題と同様に。 [Bello94a、Clark94、Ghisel94]
These white papers, a Next Generation Requirements (ngreq) BOF (chaired by Jon Crowcroft and Frank Kastenholz) held during the March 1994 Seattle IETF meeting, discussions within the IPng Area Directorate and considerable discussion on the big-internet mailing list were all used by Frank Kastenholz and Craig Partridge in revising their earlier criteria draft [Kasten92] to produce "Technical Criteria for Choosing IP The Next Generation (IPng)." [Kasten94] This document is the "clear and concise set of technical requirements and decision criteria for IPng" called for in the charge from the IESG Chair. We used this document as the basic guideline while evaluating the IPng proposals.
これらの白書、BOF(ジョン・クロウクロフトとフランクKastenholzによってまとめられる)が1994年3月のシアトルのIETFミーティングの間に持っていたNext Generation Requirements(ngreq)、IPng Area Directorateの中の議論と大きいインターネットメーリングリストについてのかなりの議論が「IP次世代(IPng)を選ぶ技術的な評価基準」を生産するために、彼らの以前の評価基準草稿[Kasten92]を改訂する際にフランクKastenholzとクレイグPartridgeによってすべて使用されました。 [Kasten94] このドキュメントはIESG議長からの充電で求められた「IPngのための技術的要求事項と決定基準の明確で簡潔なセット」です。 私たちはIPng提案を評価している間、基本のガイドラインとしてこのドキュメントを使用しました。
6.1 The IPng Technical Criteria document
6.1 IPng Technical Criteriaドキュメント
The criteria described in this document include: (from Kasten94)
本書では説明された評価基準は: (Kasten94からの)
* complete specification - The proposal must completely describe the
proposed protocol. We must select an IPng by referencing specific
documents, not to future work.
* architectural simplicity - The IP-layer protocol should be as
simple as possible with functions located elsewhere that are more
appropriately performed at protocol layers other than the IP layer.
* scale - The IPng Protocol must allow identifying and addressing at
least 10**9 leaf-networks (and preferably much more)
* topological flexibility - The routing architecture and protocols
ofIPng must allow for many different network topologies. They must
not assume that the network's physical structure is a tree.
* performance - A state of the art, commercial grade router must be
able to process and forward IPng traffic at speeds capable of fully
* 完全な仕様--提案は提案されたプロトコルについて完全に説明しなければなりません。 私たちは、今後の活動で選択するのではなく、特定のドキュメントに参照をつけることによって、IPngを選択しなければなりません。 * 建築簡単さ--IP-層のプロトコルはできるだけIP層以外のプロトコル層で、より適切に実行されるほかの場所に位置した機能で簡単であるべきです。 * 比例してください--IPngプロトコルは、少なくとも10の**9つの葉ネットワーク(望ましくははるかに)が*位相的な柔軟性であると特定して、扱うのを許容しなければなりません--ルーティングアーキテクチャとプロトコルofIPngは多くの異なったネットワークtopologiesを考慮しなければなりません。 彼らは、ネットワークの物理構造が木であると仮定してはいけません。 * 性能--ルータが処理して、できる速度でトラフィックをIPngに完全に送ることができなければならない最先端の、そして、商業のグレード
Bradner & Mankin [Page 9] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[9ページ]RFC1752推薦
utilizing common, commercially available, high-speed media at the
time.
* robust service - The network service and its associated routing and
control protocols must be robust.
* transition - The protocol must have a straightforward transition
plan from IPv4.
* media independence - The protocol must work across an internetwork
of many different LAN, MAN, and WAN media, with individual link
speeds ranging from a ones-of-bits per second to hundreds of
gigabits per second.
* datagram service - The protocol must support an unreliable datagram
delivery service.
* configuration ease - The protocol must permit easy and largely
distributed configuration and operation. Automatic configuration of
hosts and routers is required.
* security - IPng must provide a secure network layer.
* unique names - IPng must assign unique names to all IP-Layer
objects in the global, ubiquitous, Internet. These names may or
may not have any location, topology, or routing significance.
* access to standards - The protocols that define IPng and its
associated protocols should be as freely available and
redistributable as the IPv4 and related RFCs. There must be no
specification-related licensing fees for implementing or selling
IPng software.
* multicast support - The protocol must support both unicast and
multicast packet transmission. Dynamic and automatic routing of
multicasts is also required.
* extensibility - The protocol must be extensible; it must be able
to evolve to meet the future service needs of the Internet. This
evolution must be achievable without requiring network-wide
software upgrades.
* service classes - The protocol must allow network devices to
associate packets with particular service classes and provide them
with the services specified by those classes.
* mobility - The protocol must support mobile hosts, networks and
internetworks.
* control protocol - The protocol must include elementary support for
testing and debugging networks. (e.g., ping and traceroute)
* tunneling support - IPng must allow users to build private
internetworks on top of the basic Internet Infrastructure. Both
private IP-based internetworks and private non-IP-based (e.g., CLNP
or AppleTalk) internetworks must be supported.
当時一般的で、商業的に利用可能で、高速なメディアを利用します。 * 体力を要しているサービス--そのネットワーク・サービス、関連ルーティング、および制御プロトコルは体力を要するに違いありません。 * 変遷--プロトコルには、IPv4からの簡単な変遷プランがなければなりません。 * メディア独立--プロトコルは多くの異なったLAN、MAN、およびWANメディアのインターネットワークの向こう側に働かなければなりません、個々のリンク速度が1秒あたりbpsの1つ〜何百ものギガビットまで及んでいて。 * データグラムサービス--プロトコルは、頼り無いデータグラム配信がサービスであるとサポートしなければなりません。 * 構成の容易さ--プロトコルは簡単で主に分散している構成と操作を可能にしなければなりません。 ホストとルータの自動構成が必要です。 * セキュリティ--IPngは安全なネットワーク層を提供しなければなりません。 * ユニークな名前--IPngはグローバルで、遍在しているインターネットのすべてのIP-層のオブジェクトにユニークな名前を割り当てなければなりません。 これらの名前には、どんな位置、トポロジー、またはルーティング意味もあるかもしれません。 * 規格へのアクセス--IPngを定義するプロトコルとその関連プロトコルは、IPv4と関連するRFCsと自由に同じくらい利用可能であって、同じくらい再配付可能であるはずです。 ソフトウェアをIPngに実装するか、または販売するためのどんな仕様関連の認可料金もあるはずがありません。 * マルチキャストサポート--プロトコルはユニキャストとマルチキャストパケット伝送の両方をサポートしなければなりません。 また、マルチキャストのダイナミックで自動であるルーティングが必要です。 * 伸展性--プロトコルは広げることができるに違いありません。 それは、インターネットの将来のサービス需要を満たすために発展できなければなりません。 ネットワーク全体のソフトウェアの更新を必要としないで、この発展は達成可能であるに違いありません。 * サービスのクラス--プロトコルで、ネットワークデバイスは、特定のサービスのクラスにパケットを関連づけて、それらのクラスによって指定されたサービスをそれらに提供しなければなりません。 * 移動性--プロトコルはモバイルホスト、ネットワーク、およびインターネットワークをサポートしなければなりません。 * 制御プロトコル--プロトコルはネットワークをテストして、デバッグする基本のサポートを含まなければなりません。 (例えば、ピングとトレースルート) * トンネリングサポート--IPngはユーザに基本的なインターネットInfrastructureの上で個人的なインターネットワークを築き上げさせなければなりません。 プライベートアイピーベースのインターネットワークと個人的な非IPベース(例えば、CLNPかAppleTalk)のインターネットワークの両方をサポートしなければなりません。
Bradner & Mankin [Page 10] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[10ページ]RFC1752推薦
7. IPng Proposals
7. IPng提案
By the time that the IPng Area was formed, the IETF had already aimed a considerable amount of IETF effort at solving the addressing and routing problems of the Internet. Several proposals had been made and some of these reached the level of having a working group chartered. A number of these groups subsequently merged forming groups with a larger consensus. These efforts represented different views on the issues which confront us and sought to optimize different aspects of the possible solutions.
IPng Areaが形成される時までには、IETFは既にインターネットのアドレシングとルーティング問題を解決するのにかなりの量のIETF取り組みを目的としました。 いくつかの提案をしました、そして、これらの或るものはワーキンググループをチャーターさせるレベルに達しました。 これらの数は、より大きいコンセンサスを伴う次に合併している形成グループを分類します。 これらの取り組みは、私たちに立ち向かう問題で異なった視点を表して、可能なソリューションの異なった局面を最適化しようとしました。
By February 1992 the Internet community developed four separate proposals for IPng [Gross92], "CNAT" [Callon92a], "IP Encaps" [Hinden92a], "Nimrod" [Chiappa91], and "Simple CLNP" [Callon92b]. By December 1992 three more proposals followed; "The P Internet Protocol" (PIP) [Tsuchiya92], "The Simple Internet Protocol" (SIP) [Deering92] and "TP/IX" [Ullmann93]. After the March 1992 San Diego IETF meeting "Simple CLNP" evolved into "TCP and UDP with Bigger Addresses" (TUBA) [Callon92c] and "IP Encaps" evolved into "IP Address Encapsulation" (IPAE) [Hinden92b].
1992年2月までには、インターネットコミュニティはIPng[Gross92]、"CNAT"[Callon92a]、「IP Encaps」[Hinden92a]、「ニムロデ」[Chiappa91]、および「簡単なCLNP」[Callon92b]のために4つの別々の提案を開発しました。 1992年12月までには、もう3つの提案が従いました。 「Pインターネットプロトコル」(種)[Tsuchiya92]、「簡単なインターネットプロトコル」(一口)[Deering92]、および「TP/IX。」[Ullmann93] 1992年3月のサンディエゴIETFミーティング「簡単なCLNP」が「より大きいアドレスがあるTCPとUDP」に発展した後に、(tuba)[Callon92c]と「IP Encaps」は「IPアドレスカプセル化」(IPAE)[Hinden92b]に発展しました。
By November 1993, IPAE merged with SIP while still maintaining the name SIP. This group then merged with PIP and the resulting working group called themselves "Simple Internet Protocol Plus" (SIPP). At the same time the TP/IX Working Group changed its name to "Common Architecture for the Internet" (CATNIP).
1993年11月までには、IPAEはまだSIPという名前を維持している間、SIPと合併しました。 次に、このグループはPIPと合併しました、そして、結果として起こるワーキンググループは自分たちを「簡単なインターネットプロトコルプラス」(SIPP)と呼びました。 同時に、TP/IX作業部会は「インターネットへの一般的なアーキテクチャ」(CATNIP)に改名しました。
None of these proposals were wrong nor were others right. All of the proposals would work in some ways providing a path to overcome the obstacles we face as the Internet expands. The task of the IPng Area was to ensure that the IETF understand the offered proposals, learn from the proposals and provide a recommendation on what path best resolves the basic issues while providing the best foundation upon which to build for the future.
これらの提案のいずれも間違っていませんでした、そして、他のものは正しくはありませんでした。 提案のすべてが、インターネットが広がるとき私たちが直面している障害を克服するためにある点では経路を提供しながら、働いているでしょう。 IPng Areaに関するタスクはどんな経路が未来に建てる最も良い基礎を提供している間初版を特に解決するかに関して、IETFが提供された提案を理解して、提案から学んで、推薦を提供するのを保証することでした。
The IPng Area evaluated three IPng proposals as they were described in their RFC 1550 white papers: CATNIP [McGovern94] , SIPP [Hinden94a] and TUBA. [Ford94a]. The IESG viewed Nimrod as too much of a research project for consideration as an IPng candidate. Since Nimrod represents one possible future Internet routing strategy we solicited a paper describing any requirements Nimrod would put on an IPng to add to the requirements process. [Chiappa94]
それらが自己のRFC1550白書で説明されたとき、IPng Areaは3つのIPng提案を評価しました: キャットニップ[McGovern94]、SIPP[Hinden94a]、およびチューバ。 [Ford94a。] IESGは大した過ぎる研究計画としてIPng候補としての考慮に関してニムロデを見なしました。 ニムロデが1つの可能な将来のインターネット・ルーティング戦略を表すので、私たちは要件の過程に加えるためにニムロデがIPngに置くどんな要件についても説明する論文に請求しました。 [Chiappa94]
7.1 CATNIP
7.1 キャットニップ
"Common Architecture for the Internet (CATNIP) was conceived as a convergence protocol. CATNIP integrates CLNP, IP, and IPX. The CATNIP design provides for any of the transport layer protocols in use, for
「インターネット(CATNIP)への一般的なArchitectureは集合プロトコルとして発想されました。」 CATNIPはCLNP、IP、およびIPXを統合します。 CATNIPデザインは使用中のトランスポート層プロトコルのいずれにも備えます。
Bradner & Mankin [Page 11] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[11ページ]RFC1752推薦
example TP4, CLTP, TCP, UDP, IPX and SPX, to run over any of the network layer protocol formats: CLNP, IP (version 4), IPX, and CATNIP. With some attention paid to details, it is possible for a transport layer protocol (such as TCP) to operate properly with one end system using one network layer (e.g., IP version 4) and the other using some other network protocol, such as CLNP." [McGovern94]
ネットワーク層のどれかの上の走行への例のTP4、CLTP、TCP、UDP、IPX、およびSPXは形式について議定書の中で述べます: CLNP、IP(バージョン4)、IPX、およびキャットニップ。 「何らかの注意を詳細に向けていて、片端システムが1つのネットワーク層(例えば、IPバージョン4)を使用していて、もう片方がある他のネットワーク・プロトコルを使用している状態でトランスポート層プロトコル(TCPなどの)が適切に作動するのは、可能です、CLNPなどのように。」 [McGovern94]
"The objective is to provide common ground between the Internet, OSI, and the Novell protocols, as well as to advance the Internet technology to the scale and performance of the next generation of internetwork technology."
「目的は、インターネットと、OSIと、ノベルプロトコルの間に共通基盤を供給して、インターネットワーク技術の次世代のスケールと性能にインターネット技術を進めることです。」
"CATNIP supports OSI Network Service Access Point (NSAP) format addresses. It also uses cache handles to provide both rapid identification of the next hop in high performance routing as well as abbreviation of the network header by permitting the addresses to be omitted when a valid cache handle is available. The fixed part of the network layer header carries the cache handles." [Sukonnik94]
「CATNIPはOSI Network Service Access Point(NSAP)形式アドレスをサポートします。」 また、それは、有効なキャッシュハンドルが利用可能であるときにアドレスが省略されることを許可することによって高性能ルーティングにおける、次のホップの急速な識別とネットワークヘッダーの略語の両方を提供するのにキャッシュハンドルを使用します。 「ネットワーク層ヘッダーの固定一部がキャッシュハンドルを運びます。」 [Sukonnik94]
7.2 SIPP
7.2 SIPP
"Simple Internet Protocol Plus (SIPP) is a new version of IP which is designed to be an evolutionary step from IPv4. It is a natural increment to IPv4. It was not a design goal to take a radical step away from IPv4. Functions which work in IPv4 were kept in SIPP. Functions which didn't work were removed. It can be installed as a normal software upgrade in internet devices and is interoperable with the current IPv4. Its deployment strategy was designed to not have any 'flag' days. SIPP is designed to run well on high performance networks (e.g., ATM) and at the same time is still efficient for low bandwidth networks (e.g., wireless). In addition, it provides a platform for new internet functionality that will be required in the near future." [Hinden94b]
「簡単なインターネットプロトコルPlus(SIPP)はIPv4からの進化論のステップになるように設計されているIPの新しいバージョンです。」 それはIPv4への自然な増分です。 それはIPv4から遠くで急進的なステップで取るデザイン目標ではありませんでした。 IPv4で働いている機能はSIPPに保たれました。 働いていなかった機能を取り除きました。 それは、通常のソフトウェアの更新としてインターネット装置にインストールできて、現在のIPv4と共に共同利用できます。 展開戦略は、どんな'旗'も何日も持たないように設計されました。 SIPPは高性能ネットワーク(例えば、ATM)で順調であるように設計されていて、低い帯域幅ネットワーク(例えば、無線電信)には、同時に、まだ効率的です。 「さらに、近い将来必要である新しいインターネットの機能性にプラットホームを提供します。」 [Hinden94b]
"SIPP increases the IP address size from 32 bits to 64 bits, to support more levels of addressing hierarchy and a much greater number of addressable nodes. SIPP addressing can be further extended, in units of 64 bits, by a facility equivalent to IPv4's Loose Source and Record Route option, in combination with a new address type called 'cluster addresses' which identify topological regions rather than individual nodes."
「SIPPは階層構造とアドレス可能なノードのはるかに大きい数を記述するより多くのレベルを支持するためにIPアドレスサイズを32ビットから64ビットまで増加させます。」 「さらにSIPPアドレシングを広げることができます、64ビットの単位で、IPv4のLoose SourceとRecord Routeオプションに同等な施設のそばで、個々のノードよりむしろ位相的な領域を特定する'クラスタアドレス'と呼ばれる新しいアドレスタイプと組み合わせて。」
"SIPP changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. A new capability is added to enable the labeling of packets belonging to particular traffic 'flows' for which the sender requests special handling, such as non-default quality of service or 'real-
「IPヘッダーオプションがコード化される方法におけるSIPP変化は、より効率的な推進、オプションの長さにおけるそれほど厳しくない限界、および将来新しいオプションを紹介するための、より大きい柔軟性を考慮します。」 新しい能力は、送付者がサービスの質か'本当'の状態で非デフォルトなどの特別な取り扱いを要求する特定の交通'流れ'に属すパケットのラベリングを可能にするために加えられます。
Bradner & Mankin [Page 12] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[12ページ]RFC1752推薦
time' service." [Hinden94a]
「'時間'サービス。」 [Hinden94a]
7.3 TUBA
7.3 チューバ
"The TCP/UDP Over CLNP-Addressed Networks (TUBA) proposal seeks to minimize the risk associated with migration to a new IP address space. In addition, this proposal is motivated by the requirement to allow the Internet to scale, which implies use of Internet applications in a very large ubiquitous worldwide Internet. It is therefore proposed that existing Internet transport and application protocols continue to operate unchanged, except for the replacement of 32-bit IP addresses with larger addresses. TUBA does not mean having to move over to OSI completely. It would mean only replacing IP with CLNP. TCP, UDP, and the traditional TCP/IP applications would run on top of CLNP." [Callon92c]
「TCP/UDP Over CLNPによって記述されたNetworks(tuba)提案は移動に関連している危険を新しいIPアドレス空間に最小にしようとします。」 さらに、インターネットが比例するのを許容するという要件によってこの提案は動機づけられています。(それは、非常に大きい遍在している世界的なインターネットでのインターネットアプリケーションの使用を含意します)。 したがって、既存のインターネット輸送とアプリケーション・プロトコルが、変わりがない状態で作動し続けているよう提案されます、より大きいアドレスとの32ビットのIPアドレスの交換を除いて。 TUBAは、OSIに完全に譲らなければならないことを意味しません。 それは、IPをCLNPに取り替えるだけであることを意味するでしょう。 「TCP、UDP、および伝統的なTCP/IPアプリケーションはCLNPの上を走るでしょう。」 [Callon92c]
"The TUBA effort will expand the ability to route Internet packets by using addresses which support more hierarchy than the current Internet Protocol (IP) address space. TUBA specifies the continued use of Internet transport protocols, in particular TCP and UDP, but specifies their encapsulation in ISO 8473 (CLNP) packets. This will allow the continued use of Internet application protocols such as FTP, SMTP, TELNET, etc. TUBA seeks to upgrade the current system by a transition from the use of IPv4 to ISO/IEC 8473 (CLNP) and the corresponding large Network Service Access Point (NSAP) address space." [Knopper94]
「TUBAの努力は現在のインターネットプロトコル(IP)アドレス空間より多くの階層構造をサポートするアドレスを使用することによってインターネットパケットを発送する能力を広くするでしょう。」 TUBAはインターネットトランスポート・プロトコル、特にTCP、およびUDPの継続的な使用を指定しますが、ISO8473(CLNP)パケットでそれらのカプセル化を指定します。 これはFTP、SMTP、TELNETなどのインターネットアプリケーション・プロトコルの継続的な使用を許すでしょう。 「TUBAはIPv4の使用からISO/IEC8473(CLNP)までの変遷と対応する大きいNetwork Service Access Point(NSAP)アドレス空間で現在のシステムをアップグレードさせようとします。」 [Knopper94]
"The TUBA proposal makes use of a simple long-term migration proposal based on a gradual update of Internet Hosts (to run Internet applications over CLNP) and DNS servers (to return larger addresses). This proposal requires routers to be updated to support forwarding of CLNP (in addition to IP). However, this proposal does not require encapsulation nor translation of packets nor address mapping. IP addresses and NSAP addresses may be assigned and used independently during the migration period. Routing and forwarding of IP and CLNP packets may be done independently." ([Callon92c]
「TUBA提案はインターネットHosts(CLNPでインターネットアプリケーションを実行する)とDNSサーバ(より大きいアドレスを返す)のゆるやかなアップデートに基づく簡単な長期の移動提案を利用します。」 この提案は、CLNP(IPに加えた)のサポート推進にルータをアップデートするのを必要とします。 または、しかしながら、この提案はカプセル化が必要でない、パケットに関する翻訳、または、アドレス・マッピング。 IPアドレスとNSAPアドレスは、移動の期間、独自に割り当てられて、使用されるかもしれません。 「独自にIPとCLNPパケットのルート設定と推進をするかもしれません。」 ([Callon92c]
8. IPng Proposal Reviews
8. IPng提案レビュー
The IPng Directorate discussed and reviewed the candidate proposals during its biweekly teleconferences and through its mailing list. In addition, members of the Big-Internet mailing list discussed many of the aspects of the proposals, particularly when the Area Directors posted several specific questions to stimulate discussion. [Big]
IPng Directorateは隔週の電子会議とそのメーリングリストを通した候補提案について議論して、見直しました。 さらに、Big-インターネットメーリングリストのメンバーは提案の局面の多くについて議論しました、特にAreaディレクターが議論を刺激するためにいくつかの具体的な質問を掲示したとき。 [大きい]
The directorate members were requested to each evaluate the proposals in preparation for a two day retreat held near Chicago on May 19th and 20th 1994. The retreat opened with a roundtable airing of the
管理職のメンバーがそれぞれ2日間の5月19日と20番目の1994でシカゴの近くで行われる後退に備えて提案を評価するよう要求されました。 討論会が放送している状態で、後退は開きました。
Bradner & Mankin [Page 13] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[13ページ]RFC1752推薦
views of each of the participants, including the Area Directors, the Directorate and a number of guests invited by the working group chairs for each for the proposals. [Knopper94b] We will publish these reviews as well as a more detailed compendium review of each of the proposals as companion memos.
提案のためにワーキンググループいすによってそれぞれに招待されたAreaディレクター、Directorate、および多くの客を含む関係者各人の視点。 [Knopper94b] 私たちはそれぞれの提案の、より詳細な概要レビューと同様に仲間メモとしてこれらのレビューを発行するつもりです。
The following table summarizes each of the three proposals reviewed against the requirements in the IPng Criteria document. They do not necessarily reflect the views of the Area Directors. "Yes" means the reviewers mainly felt the proposal met the specific criterion. "No" means the reviewers mainly felt the proposal did not meet the criterion. "Mixed" means that the reviewers had mixed reviews with none dominating. "Unknown" means that the reviewers mainly felt the documentation did not address the criterion.
以下のテーブルはIPng Criteriaドキュメントの要件に対して見直されたそれぞれの3つの提案をまとめます。 彼らは必ずAreaディレクターの視点を反映するというわけではありません。 「はい」は、評論家が、提案が特定の評価基準を満たしたと主に感じたことを意味します。 「いいえ」は、評論家が、提案が評価基準を満たさなかったと主に感じたことを意味します。 「Mixed」は、評論家が支配していないなにもレビューを混ぜたことを意味します。 「未知」は、評論家が、ドキュメンテーションが評価基準を記述しなかったと主に感じたことを意味します。
CATNIP SIPP TUBA
------ ---- ----
complete spec no yes mostly
simplicity no no no
scale yes yes yes
topological flex yes yes yes
performance mixed mixed mixed
robust service mixed mixed yes
transition mixed no mixed
media indepdnt yes yes yes
datagram yes yes yes
config. ease unknown mixed mixed
security unknown mixed mixed
unique names mixed mixed mixed
access to stds yes yes mixed
multicast unknown yes mixed
extensibility unknown mixed mixed
service classes unknown yes mixed
mobility unknown mixed mixed
control proto unknown yes mixed
tunneling unknown yes mixed
キャットニップSIPPチューバ------ ---- ---- 強健な状態で混ぜられて、はい、ほとんどどんなスケールはいはいはいの位相的な屈曲はいはいはい性能も混ぜなかった簡単さノー、は混入しました。完全な仕様ノー、サービスの複雑な複雑なはい変遷は混合媒体indepdntはいはいはいデータグラムはいはいはいコンフィグを全く混ぜませんでした; 未知の複雑な複雑なセキュリティ未知の複雑な複雑なユニークな名が混ぜた容易さは未知のはい複雑なトンネルの未知のはいが混ぜたstdsはいはいの未知のはい複雑な移動性の未知の混ぜられた混ぜられたコントロール複雑な未知の複雑なマルチキャストの伸展性未知の複雑な複雑なサービスのはいクラスprotoへの複雑なアクセスを混ぜました。
8.1 CATNIP Reviews
8.1 キャットニップレビュー
All the reviewers felt that CATNIP is not completely specified. However, many of the ideas in CATNIP are innovative and a number of reviewers felt CATNIP shows the best vision of all of the proposals. The use of Network Service Attachment Point Addresses (NSAPs) is well thought out and the routing handles are innovative.
すべての評論家が、CATNIPが完全に指定されるというわけではないと感じました。 しかしながら、CATNIPの考えの多くが革新的です、そして、多くの評論家がCATNIPが提案のすべての最も良いビジョンを示すと感じました。 Network Service Attachment Point Addresses(NSAPs)の使用はよく考え抜かれます、そして、ルーティングハンドルは革新的です。
While the goal of uniting three major protocol families, IP, ISO-CLNP and Novell IPX is laudable our consensus was that the developers had not developed detailed enough plans to support realizing that goal.
3の主要なプロトコルの家族、IP、ISO-CLNP、およびノベルIPXを結合させるという目標はあっぱれですが、私たちのコンセンサスは開発者がその目標がわかるのを支持する十分詳細な計画を開発していなかったということでした。
Bradner & Mankin [Page 14] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[14ページ]RFC1752推薦
The plans they do describe suffer from the complexity of trying to be the union of a number of existing network protocols. Some reviewers felt that CATNIP is basically maps IPv4, IPX, and SIPP addresses into NSAPs and, as such, does not deal with the routing problems of the current and future Internet.
それらが説明するプランは多くの既存のネットワーク・プロトコルの組合になろうとする複雑さに苦しみます。 CATNIPが基本的にそうである、ある評論家フェルトは、IPv4、IPX、およびSIPPアドレスをNSAPsに写像して、そういうものとして現在の、そして、将来のインターネットのルーティング問題に対処しません。
Additionally the reviewers felt that CATNIP has poor support for multicasting and mobility and does not specifically deal with such important topics as security and autoconfiguration.
さらに、評論家は、CATNIPがマルチキャスティングと移動性の不十分なサポートを持って、明確にセキュリティと自動構成のような重要な話題に対処しないと感じました。
8.2 SIPP Reviews
8.2 SIPPレビュー
Most of the reviewers, including those predisposed to other proposals, felt as one reviewer put it, that SIPP is an "aesthetically beautiful protocol well tailored to compactly satisfy today's known network requirements." The SIPP Working Group has been the most dynamic over the last year, producing a myriad of documentation detailing almost all of the aspects necessary to produce a complete protocol description.
他の提案に前処理されたものを含む評論家の大部分は、1人の評論家がそれを表現したようにそのSIPPが「コンパクトに今日の知られているネットワーク要件を満たすためによく合わせた美しく美しいプロトコル」であると感じました。 SIPP作業部会は最後の1年間、最もダイナミックです、完全なプロトコル記述を起こすのに必要な局面のほとんどすべてを詳しく述べるドキュメンテーションの無数を生産して。
The biggest problem the reviewers had with SIPP was with IPAE, SIPP's transition plan. The overwhelming feeling was that IPAE is fatally flawed and could not be made to work reliably in an operational Internet.
評論家がSIPPと共に持っていた中で最も大きい問題がIPAE、SIPPの変遷プランと共にありました。 圧倒的な感じはIPAEは致命的に失敗して、操作上のインターネットで確かに働かされることができなかったということでした。
There was significant disagreement about the adequacy of the SIPP 64 bit address size. Although you can enumerate 10**15 end nodes in 64 bits people have different views about how much inefficiency real- world routing plans introduce. [Huitema94] The majority felt that 64 bit addresses do not provide adequate space for the hierarchy required to meet the needs of the future Internet. In addition since no one has any experience with extended addressing and routing concepts of the type proposed in SIPP, the reviewers generally felt quite uncomfortable with this methodology. The reviewers also felt that the design introduces some significant security issues.
SIPP64ビット・アドレスサイズの妥当性に関して重要な不一致がありました。 あなたは10**を列挙できますが、64ビットの人々の15のエンドノードには、非能率の本当の世界ルーティングプランがどのくらい導入するかに関する異なった意見があります。 [Huitema94] 64のビット・アドレスが適切なスペースを階層構造に提供しないと感じられた大部分が将来のインターネットの需要を満たすのが必要です。 一般に、だれにもSIPPで提案されるタイプの拡張アドレシングとルーティング概念のどんな経験もなくて以来の添加では、評論家はこの方法論でかなり不快に感じました。 また、評論家は、デザインがいくつかの重要な安全保障問題を紹介すると感じました。
A number of reviewers felt that SIPP did not address the routing issue in any useful way. In particular, there has been no serious attempt made at developing ways to abstract topology information or to aggregate information about areas of the network.
多くの評論家が、SIPPがどんな役に立つ方法でもルーティング問題を記述しなかったと感じました。 特に、抽象的なトポロジー情報への展開しているようにおいて、または、ネットワークの領域の集合情報にされたどんな重大な試みもありませんでした。
Finally, most of the reviewers questioned the level of complexity in the SIPP autoconfiguration plans as well as in SIPP in general, other than the header itself.
最終的に、評論家の大部分はSIPP自動構成プランと一般に、SIPPの複雑さのレベルに質問しました、ヘッダー自体を除いて。
Bradner & Mankin [Page 15] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[15ページ]RFC1752推薦
8.3 TUBA Reviews
8.3 チューバレビュー
The reviewers generally felt that the most important thing that TUBA has offers is that it is based on CLNP and there is significant deployment of CLNP-capable routers throughout the Internet. There was considerably less agreement that there was significant deployment of CLNP-capable hosts or actual networks running CLNP. Another strong positive for TUBA is the potential for convergence of ISO and IETF networking standards. A number of reviewers pointed out that, if TUBA were to be based on a changed CLNP then the advantage of an existing deployed infrastructure would be lost and that the convergence potential would be reduced.
一般に、評論家は、TUBAには申し出があるとそんなに最も重要なものと感じました。CLNPに基づいているということであり、インターネット中にCLNPできるルータの重要な展開があります。 CLNP有能なホストかCLNPを走らせる実際のネットワークの重要な展開があったというかなり少ない協定がありました。 別のTUBAに、強い正数は規格をネットワークでつなぐISOとIETFの集合の可能性です。 多くの評論家がそれを指摘しました、そして、インフラストラクチャは次に、変えられたCLNPに基づいたTUBAによる配備された存在の利点であるなら失われているでしょうに、そして、集合の可能性は減少するでしょう。
A number of aspects of CLNP were felt to be a problem by the reviewers including the inefficiencies introduced by the lack of any particular word alignment of the header fields, CLNP source route, the lack of a flow ID field, the lack of a protocol ID field, and the use of CLNP error messages in TUBA. The CLNP packet format or procedures would have to be modified to resolve at least some of these issues.
CLNPの多くの局面がTUBAにおけるヘッダーフィールドのどんな特定の単語整列の不足、CLNP送信元経路、流れID分野の不足、プロトコルID分野の不足、およびCLNPエラーメッセージの使用でも導入された非能率を含む評論家による問題であると感じられました。 CLNPパケット・フォーマットか手順が、少なくともこれらの問題のいくつかを解決するように変更されなければならないでしょう。
There seems to be a profound disagreement within the TUBA community over the question of the ability of the IETF to modify the CLNP standards. In our presentation in Houston we said that we felt that "clone and run" was a legitimate process. This is also what the IAB proposed in "IP version 7". [IAB92] The TUBA community has not reached consensus that this view is reasonable. While many, including a number of the CLNP document authors, are adamant that this is not an issue and the IETF can make modifications to the base standards, many others are just as adamant that the standards can only be changed through the ISO standards process. Since the overwhelming feeling within the IETF is that the IETF must 'own' the standards on which it is basing its future, this disagreement within the TUBA community was disquieting.
深遠な不一致はIETFがCLNP規格を変更する能力の問題の上でTUBA共同体の中であるように思えます。 ヒューストンでのプレゼンテーションでは、私たちは、「クローンを作ってください、そして、走ってください」が正統の過程であると感じたと言いました。 また、これがIABが提案したことである、「IP、バージョン7インチ」 [IAB92] TUBA共同体はこの視点が妥当であるというコンセンサスに達していません。 多くのCLNPドキュメント作者を含む多くは問題とIETFではなく、金剛不懐がベース規格への変更をすることができるということですが、ISO標準化過程で変えて、多くの他のものはまさしく金剛不懐であるとして規格があることができるだけであることです。 以来IETFの中の圧倒的な感じがIETFがそれが未来を基礎づけている規格を'所有しなければならない'ということである、TUBA共同体の中のこの不一致は不穏であることでした。
For a number of reasons, unfortunately including prejudice in a few cases, the reviews of the TUBA proposals were much more mixed than for SIPP or CATNIP. Clearly TUBA meets the requirements for the ability to scale to large numbers of hosts, supports flexible topologies, is media independent and is a datagram protocol. To the reviewers, it was less clear that TUBA met the other IPng requirements and these views varied widely.
残念ながら、いくつかのケースに偏見を含んでいて、様々な意味で、TUBA提案のレビューはSIPPかCATNIPよりはるかに複雑でした。 明確に、TUBAは多くのホストに比例する能力のために条件を満たして、フレキシブルなtopologiesを支持して、メディア独立者であり、データグラムプロトコルです。 評論家には、TUBAが他のIPng必要条件を満たしたのが、それほど明確でなく、これらの視点はばらつきが大きかったです。
There was also disagreement over the advisability of using NSAPs for routing given the wide variety of NSAP allocation plans. The Internet would have to restrict the use of NSAPs to those which are allocated with the actual underlying network topology in mind if the required degree of aggregation of routing information is to be
広いバラエティーのNSAP配分プランを考えて、ルーティングにNSAPsを使用する得策の上に不一致もありました。 インターネットは制限のためにNSAPsの使用を必要な度のルーティング情報の集合が割り当てるなら実際の基本的なネットワーク形態と共に念頭に割り当てるものに制限しなければならないでしょう。
Bradner & Mankin [Page 16] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[16ページ]RFC1752推薦
achieved.
達成にされる。
8.4 Summary of Proposal Reviews
8.4 提案レビューの概要
To summarize, significant problems were seen in all three of the proposals. The feeling was that, to one degree or another, both SIPP and TUBA would work in the Internet context but each exhibited its own problems. Some of these problems would have to be rectified before either one would be ready to replace IPv4, much less be the vehicle to carry the Internet into the future. Other problems could be addressed over time. CATNIP was felt to be too incomplete to be considered.
まとめるために見る、重大な問題はすべての3つの提案で見られました。 感じはこれらの問題のいくつかがどちらかがIPv4を取り替える準備ができている前に正されるために持っている何らかの度(SIPPとTUBAがインターネット文脈にもかかわらず、それぞれ示されたそれ自身の問題で扱う両方)への多くが未来までインターネットを運ぶより乗り物以下であるということでした。 時間がたつにつれて、他の問題を記述できました。 CATNIPは考えることができないくらい不完全であると感じられました。
9. A Revised Proposal
9. 改訂された提案
As mentioned above, there was considerable discussion of the strengths and weaknesses of the various IPng proposals during the IPng 'BigTen' retreat on May 19th and 20th 1994. [Knopper94b] After this retreat Steve Deering and Paul Francis, two of the co-chairs of the SIPP Working Group, sent a message to the sipp mailing list detailing the discussions at the retreat and proposing some changes in SIPP. [Deering94a]
以上のように、強さのかなりの議論と様々なIPng提案の弱点が5月19日と20番目の1994におけるIPng'BigTen'後退の間、ありました。 [Knopper94b] この後退の後に、スティーブ・デアリングとSIPP作業部会の2人の共同議長歳のポール・フランシスは隠れ家で議論を詳しく述べて、SIPPでいくつかの変化を提案するsippメーリングリストにメッセージを送りました。 [Deering94a]
The message noted "The recurring (and unsurprising) concerns about SIPP were:
「SIPPに関する再発していて(驚くほどでない)の心配は以下の通りでした。」と、メッセージは述べました。
(1) complexity/manageability/feasibility of IPAE, and
そして(1) IPAEに関する複雑さ/管理可能性/実現の可能性。
(2) adequacy/correctness/limitations of SIPP's addressing and routing
model, especially the use of loose source routing to accomplish
'extended addressing'".
「(2) SIPPの妥当性/正当性/限界がモデルに演説して、発送して、特に達成するゆるいソースルーティングの使用は'アドレシングを広げました'。」
They "proposed to address these concerns by changing SIPP as follows:
それら、「提案されて、これらを記述するのは以下のSIPPを変えることによって、以下に関係があります」。
* Change address size from 8 bytes to 16 bytes (fixed-length).
* アドレスサイズを8バイトから16バイト(固定長)に変えてください。
* Specify optional use of serverless autoconfiguration of the 16-byte
address by using IEEE 802 address as the low-order ("node ID")
part.
* 下位(「ノードID」)の一部としてIEEE802アドレスを使用することによって、16バイトのアドレスのserverless自動構成の任意の使用を指定してください。
* For higher-layer protocols that use internet-layer addresses as
part of connection identifiers (e.g., TCP), require that they use
the entire 16-byte addresses.
* 接続識別子(例えば、TCP)の一部としてインターネット層のアドレスを使用する上位層プロトコルには、全体の16バイトのアドレスを使用するのを必要であってください。
* Do *not* use Route Header for extended addressing."
* 「拡張アドレシングのために*使用ではなく、*Route Headerをしてください。」
Bradner & Mankin [Page 17] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[17ページ]RFC1752推薦
After considerable discussion on the sipp and big-internet mailing lists about these proposed changes, the SIPP working group published a revised version of SIPP [Deering94b], a new addressing architecture [Francis94], and a simplified transition mechanism [Gillig94a]. These were submitted to the IPng Directorate for their consideration.
sippについてのかなりの議論とこれらに関する大きいインターネットメーリングリストが変化を提案した後に、SIPPワーキンググループはSIPPの改訂版[Deering94b]、新しいアドレッシング体系[Francis94]、および簡易型の変遷メカニズム[Gillig94a]を発表しました。 彼らの考慮のためにIPng Directorateにこれらを提出しました。
This proposal represents a synthesis of multiple IETF efforts with much of the basic protocol coming from the SIPP effort, the autoconfiguration and transition portions influenced by TUBA, the addressing structure is based on the CIDR work and the routing header evolving out of the SDRP deliberations.
基本プロトコルの多くが部分がTUBAで影響を及ぼしたSIPPの努力、自動構成、および変遷から来ていて、この提案は複数のIETFの努力の統合を表して、アドレシング構造はSDRP熟考からCIDR仕事とルーティングヘッダー発展に基づいています。
10. Assumptions
10. 仮定
10.1 Criteria Document and Timing of Recommendation
10.1推薦の評価基準ドキュメントとタイミング
In making the following recommendations we are making two assumptions of community consensus; that the IPng criteria document represents the reasonable set of requirements for an IPng, and that a specific recommendation should be made now and that from this point on the IETF should proceed with a single IPng effort.
以下の推薦状をする際に、私たちは2を共同体コンセンサスの仮定にしています。 IPng評価基準ドキュメントはIPngのための妥当なセットの要件を表します、そして、今特定の推薦状をするべきです、そして、この地点から先はIETFはただ一つのIPngの努力を続けるはずです。
As described above, the IPng Technical Criteria document [Kasten94] was developed in a open manner and was the topic of extensive discussions on a number of mailing lists. We believe that there is a strong consensus that this document accurately reflects the community's set of technical requirements which an IPng should be able to meet.
上で説明されるように、IPng Technical Criteriaドキュメント[Kasten94]は、率直な方法で開発されて、多くのメーリングリストについての大規模な議論の話題でした。 私たちは、このドキュメントが正確に共同体のIPngが満たすはずであることができる技術的要求事項のセットを反映するという強いコンセンサスがあると信じています。
A prime topic of discussion on the big-internet mailing list this spring as well as during the open IPng directorate meeting in Seattle, was the need to make a specific IPng recommendation at this time. Some people felt that additional research would help resolve some of the issues that are currently unresolved. While others argued that selecting a single protocol to work on would clarify the picture for the community, focus the resources of the IETF on finalizing its details, and, since the argument that there were open research items could be made at any point in history, there might never be a 'right' time.
今春の大きいインターネットメーリングリストと開いているIPng管理職の間の議論の主要な話題がシアトルで満たされて、必要性はこのとき、特定のIPng推薦状をすることになっていましたか? 人々の中には追加研究が、現在未定の問題のいくつかを解決するのを助けると感じた人もいました。 他のものが、ただ一つのプロトコルを選択すると働いている絵が共同体にはっきりさせられると主張していた間、詳細を成立させるのにIETFに関するリソースの焦点を合わせてください。そうすれば、'正しい'時間は、史上での任意な点で開いている研究項目があったという主張をすることができたので、決してないかもしれません。
Our reading of the community is that there is a consensus that a specific recommendation should be made now. This is consistent with the views expressed during the ipdecide BOF in Amsterdam [Gross94] and in some of the RFC 1550 white papers [Carpen94a].
私たちの共同体の読書は今特定の推薦状をするべきであるというコンセンサスがあるということです。 これはipdecide BOFの間、アムステルダム[Gross94]とRFC1550白書[Carpen94a]のいくつかで言い表される視点と一致しています。
There is no particular reason to think that the basic recommendation would be significantly different if we waited for another six months or a year. Clearly some details which are currently unresolved could
私たちが6カ月かもうの1年間待つなら基本的な推薦がかなり異なっていると考えるどんな特定の理由もありません。 明確に、いくつかの現在未定の詳細はそうすることができました。
Bradner & Mankin [Page 18] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[18ページ]RFC1752推薦
be filled in if the recommendation were to be delayed, but the current fragmentation of the IETF's energies limits the efficiency of this type of detail resolution. Concentrating the resources of the IETF behind a single effort seems to us to be a more efficient way to proceed.
推薦が遅らせられることでしたが、IETFの活力限界の現在の断片化がこのタイプの詳細分解能の効率であったなら、記入されてください。 ただ一つの努力の後ろにIETFに関するリソースを集結するのは続くより効率的な方法であるように私たちにとって思えます。
10.2 Address Length
10.2 アドレスの長さ
One of the most hotly discussed aspects of the IPng design possibilities was address size and format. During the IPng process four distinct views were expressed about these issues:
IPngデザインの可能性の最も熱心に議論された局面の1つはサイズと形式を記述することでした。 IPngの過程の間、4つの異なった視点がこれらの問題に関して言い表されました:
1. The view that 8 bytes of address are enough to meet the current
and future needs of the Internet (squaring the size of the IP
address space). More would waste bandwidth, promote inefficient
assignment, and cause problems in some networks (such as mobiles
and other low speed links).
1. 8バイトのアドレスがインターネットの現在の、そして、将来の需要を満たすことができるくらいの(IPアドレス空間のサイズを二乗して)意見。 以上は、いくつかのネットワーク(モバイルや他の低速リンクなどの)で帯域幅を浪費して、効率の悪い課題を促進して、問題を起こすでしょう。
2. The view that 16 bytes is about right. That length supports easy
auto-configuration as well as organizations with complex internal
routing topologies in conjunction with the global routing topology
now and well into the future.
2. 16バイトがほとんど正しいという意見。 その長さは未来までグローバルなルーティングトポロジーに関連して複雑な内部のルーティングtopologiesとの組織と同様に簡単な自動構成を現在、よく支持します。
3. The view that 20 byte OSI NSAPs should be used in the interests of
global harmonization.
3. 20バイトのOSI NSAPsが国際的な調和のために使用されるべきであるという意見。
4. The view that variable length addresses which might be smaller or
larger than 16 bytes should be used to embrace all the above
options and more, so that the size of the address could be
adjusted to the demands of the particular environment, and to
ensure the ability to meet any future networking requirements.
4. 可変長がどれを記述するかという意見は、特定の環境の要求にアドレスのサイズを調整できるようにすべての上のオプションとその他を受け入れて、要件をネットワークでつなぐどんな未来にも間に合う能力を確実にするために16バイトが使用されるべきであるよりさらにわずかであるか、または広いかもしれません。
Good technical and engineering arguments were made for and against all of these views. Unanimity was not achieved, but we feel that a clear majority view emerged that the use of 16 byte fixed length addresses was the best compromise between efficiency, functionality, flexibility, and global applicability. [Mankin94]
すべてを支持してこれらの視点のすべてに対して技術的、そして、工学の良い議論をしました。 満場一致は達成されませんでしたが、私たちは、16バイトの固定長アドレスの使用が効率と、機能性と、柔軟性と、グローバルな適用性の間の最も良い妥協であったという明確な大多数意見が現れたと感じます。 [Mankin94]
11. IPng Recommendation
11. IPng推薦
After a great deal of discussion in many forums and with the consensus of the IPng Directorate, we recommend that the protocol described in "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)" [Deering94b] be adopted as the basis for IPng, the next generation of the Internet Protocol. We also recommend that the other documents listed in Appendix C be adopted as the basis of specific features of this protocol.
多くのフォーラムでの大きな議論の後とIPng Directorateのコンセンサスをもって、私たちは、プロトコルが中で「簡単なインターネットプロトコルと(SIPP)仕様」について説明したことを勧めます。 (128ビットのver)「[Deering94b] IPngの基礎、インターネットプロトコルの次世代として、採用されてください。」 また、私たちは、Appendix Cにリストアップされた他のドキュメントがこのプロトコルの特定の特徴の基礎として採用されることを勧めます。
Bradner & Mankin [Page 19] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[19ページ]RFC1752推薦
This proposal resolves most of the perceived problems, particularly in the areas of addressing, routing, transition and address autoconfiguration. It includes the broad base of the SIPP proposal effort, flexible address autoconfiguration features, and a merged transition strategy. We believe that it meets the requirements outlined in the IPng Criteria document and provides the framework to fully meet the needs of the greater Internet community for the foreseeable future.
この提案は特にアドレシング、ルーティング、変遷、およびアドレス自動構成の領域で知覚された問題の大部分を解決します。 それはSIPP提案の努力の広いベース、フレキシブルなアドレス自動構成機能、および合併している変遷戦略を含んでいます。 私たちは、それがIPng Criteriaドキュメントに概説された必要条件を満たして、予見できる未来の、よりすばらしいインターネットコミュニティの需要を完全に満たすために枠組みを提供すると信じています。
11.1 IPng Criteria Document and IPng
11.1 IPng評価基準のドキュメントとIPng
A detailed review of how IPng meets the requirements set down in the IPng Criteria document [Kasten94] will soon be published. Following is our feelings about the extent to which IPng is responsive to the criteria.
IPngがどうIPng Criteriaドキュメント[Kasten94]に置かれる必要条件を満たすかに関する詳細なレビューはすぐ、発行されるでしょう。 以下に、どのIPngが評価基準に敏感であるかへの範囲に対する私たちの気持ちがあります。
* complete specification - the base specifications for IPng are
complete but transition and address autoconfiguration do remain to
be finalized
* architectural simplicity - the protocol is simple, easy to explain
and uses well established paradigms
* scale - an address size of 128 bits easily meets the need to
address 10**9 networks even in the face of the inherent
inefficiency of address allocation for efficient routing
* topological flexibility - the IPng design places no constraints on
network topology except for the limit of 255 hops
* performance - the simplicity of processing, the alignment of the
fields in the headers, and the elimination of the header checksum
will allow for high performance handling of IPng data streams
* robust service - IPng includes no inhibitors to robust service and
the addition of packet-level authentication allows the securing of
control and routing protocols without having to have separate
procedures
* transition - the IPng transition plan is simple and realistically
covers the transition methods that will be present in the
marketplace
* media independence - IPng retains IPv4's media independence, it may
be possible to make use of IPng's Flow Label in some connection-
oriented media such as ATM
* datagram service - IPng preserves datagram service as its basic
operational mode, it is possible that the use of path MTU discovery
will complicate the use of datagrams in some cases
* configuration ease - IPng will have easy and flexible address
autoconfiguration which will support a wide variety of environments
from nodes on an isolated network to nodes deep in a complex
internet
* security - IPng includes specific mechanisms for authentication and
encryption at the internetwork layer; the security features do rely
* 完全な仕様--変遷とアドレス自動構成は成立させられた*建築簡単さであることを残っています--IPngのための基礎仕様は完全ですが、プロトコルは簡単です; 128ビットのアドレスサイズは容易にアドレス10*を需要を満たします。説明する小休止と確固としているパラダイム*がスケーリングする用途--*9はIPngデザインが255ホップ*性能の限界以外のネットワーク形態に規制を全く置かないという効率的なルーティング*位相的な柔軟性のためのアドレス配分の固有の非能率に直面してさえ処理の簡単さをネットワークでつなぎます; 中のヘッダー、およびヘッダーチェックサムの除去がそうする分野の整列はIPngデータ・ストリーム*の高性能取り扱いのために体力を要しているサービスを許します--別々の手順*変遷を持つ必要はなくて、パケット・レベル認証の添加はコントロールとルーティング・プロトコルを安全にすることを許します--IPngが体力を要しているサービスに抑制剤を全く含めないで、IPng変遷プランが現実的に簡単である、カバー 市場*メディア独立で存在している変遷方法--接続におけるIPngのFlow Labelの使用をATM*データグラムサービスなどの指向のメディアにするのは可能であるかもしれません--IPngはIPv4のメディア独立を保有して、IPngは基本の操作上のモードとしてデータグラムサービスを保持します; 経路MTU探索の使用が何らかのケース*構成の容易さにおけるデータグラムの使用を複雑にするのは、可能です--IPngには、さまざまな環境を複雑なインターネット*セキュリティで深く孤立しているネットワークのノードからノードまで支持する簡単でフレキシブルなアドレス自動構成があるでしょう--IPngはインターネットワーク層に認証と暗号化のための特定のメカニズムを含んでいます。 セキュリティ機能は当てにされます。
Bradner & Mankin [Page 20] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[20ページ]RFC1752推薦
on the presence of a yet to be defined key management system
* unique names - IPng addresses may be used as globally unique names
although they do have topological significance
* access to standards - all of the IPng standards will be published
as RFCs with unlimited distribution
* multicast support - IPng specifically includes multicast support
* extensibility - the use of extension headers and an expandable
header option feature will allow the introduction of new features
into IPng when needed in a way that minimizes the disruption of the
existing network
* service classes - the IPng header includes a Flow Label which may
be used to differentiate requested service classes
* mobility - the proposed IPv4 mobility functions will work with IPng
* control protocol - IPng includes the familiar IPv4 control protocol
features
* tunneling support - encapsulation of IPng or other protocols within
IPng is a basic capability described in the IPng specifications
位相的な意味*アクセスを規格に持っていますが、IPngアドレスはグローバルにユニークな名前として使用されるかもしれません--IPng規格のすべてがRFCsとして無制限の配布*マルチキャストサポートで発行されるでしょう--IPngが明確にマルチキャストサポート*伸展性を含んでいるという拡張ヘッダーの使用と拡張可能なヘッダーオプション機能がそうするユニークな名前が新機能の導入を許すまだ定義されなかったかぎ管理システム*の存在の上で; 存在の分裂を最小にする方法で必要であると、IPngはIPngヘッダーが要求されたサービスのクラス*移動性を微分するのに使用されるかもしれないFlow Labelを入れるという提案されたIPv4移動性機能がIPng*制御プロトコルで扱う*サービスクラスをネットワークでつなぎます--IPngはサポートにトンネルを堀りながら、身近なIPv4制御プロトコル機能*を含んでいます--IPngの中のIPngか他のプロトコルのカプセル化はIPng仕様で説明された基本的な能力です。
11.2 IPv6
11.2 IPv6
The IANA has assigned version number 6 to IPng. The protocol itself will be called IPv6.
IANAはバージョンNo.6をIPngに割り当てました。 プロトコル自体はIPv6と呼ばれるでしょう。
The remainder of this memo is used to describe IPv6 and its features. This description is an overview snapshot. The standards documents themselves should be referenced for definitive specifications. We also make a number of specific recommendations concerning the details of the proposed protocol, the procedures required to complete the definition of the protocol, and the IETF working groups we feel are necessary to accomplish the task.
このメモの残りは、IPv6とその特徴について説明するのに使用されます。 この記述は概観スナップです。 規格文書自体は決定的な仕様のために参照をつけられるべきです。 また、私たちは提案されたプロトコルの詳細に関して多くの特定の推薦状をします、そして、手順がプロトコルの定義を終了するのが必要であり、私たちが感じるIETFワーキンググループが、タスクを達成するのに必要です。
12. IPv6 Overview
12. IPv6概観
IPv6 is a new version of the Internet Protocol, it has been designed as an evolutionary, rather than revolutionary, step from IPv4. Functions which are generally seen as working in IPv4 were kept in IPv6. Functions which don't work or are infrequently used were removed or made optional. A few new features were added where the functionality was felt to be necessary.
IPv6がインターネットプロトコルの新しいバージョンである、それは革命家よりむしろ進化的(IPv4からのステップ)として設計されています。 一般に、IPv4で働くのが見られる機能はIPv6に保たれました。 働いていないか、またはまれに使用される機能を、移したか、または任意にしました。 いくつかの新機能が機能性が必要であると感じられたところで加えられました。
The important features of IPv6 include: [Hinden94c]
IPv6の重要な特徴は: [Hinden94c]
* expanded addressing and routing capabilities - The IP address size
is increased from 32 bits to 128 bits providing support for a much
greater number of addressable nodes, more levels of addressing
hierarchy, and simpler auto-configuration of addresses.
* 拡張アドレシングとルーティング能力--IPアドレスサイズは32ビットからはるかに大きい数のアドレス可能なノードのサポート、より多くのレベルのアドレシング階層構造、およびアドレスの、より簡単な自動構成を提供する128ビットまで増加します。
Bradner & Mankin [Page 21] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[21ページ]RFC1752推薦
The scaleability of multicast routing is improved by adding a
"scope" field to multicast addresses.
マルチキャストルーティングのscaleabilityは、「範囲」分野をマルチキャストアドレスに追加することによって、改良されます。
A new type of address, called a "cluster address" is defined to
identify topological regions rather than individual nodes. The use
of cluster addresses in conjunction with the IPv6 source route
capability allows nodes additional control over the path their
traffic takes.
アドレスの新しいタイプであり、呼ばれて、「クラスタアドレス」は、個々のノードよりむしろ位相的な領域を特定するために定義されます。 IPv6送信元経路能力に関連したクラスタアドレスの使用はそれらの交通が取る経路の追加コントロールをノードに許します。
* simplified header format - Some IPv4 header fields have been
dropped or made optional to reduce the common-case processing cost
of packet handling and to keep the bandwidth overhead of the IPv6
header as low as possible in spite of the increased size of the
addresses. Even though the IPv6 addresses are four time longer
than the IPv4 addresses, the IPv6 header is only twice the size of
the IPv4 header.
* 簡易型のヘッダー形式--パケット取り扱いのよくある例加工費を下げて、アドレスの増加するサイズにもかかわらず、できるだけ低くIPv6ヘッダーの帯域幅オーバーヘッドを保つためにいくつかのIPv4ヘッダーフィールドを低下するか、または任意にしました。 IPv4アドレスより長い間IPv6アドレスは4時間ですが、IPv6ヘッダーはIPv4ヘッダーのサイズの2倍であるだけです。
* support for extension headers and options - IPv6 options are placed
in separate headers that are located in the packet between the IPv6
header and the transport-layer header. Since most IPv6 option
headers are not examined or processed by any router along a
packet's delivery path until it arrives at its final destination,
this organization facilitates a major improvement in router
performance for packets containing options. Another improvement is
that unlike IPv4, IPv6 options can be of arbitrary length and not
limited to 40 bytes. This feature plus the manner in which they are
processed, permits IPv6 options to be used for functions which were
not practical in IPv4.
* 拡張ヘッダーとオプションのサポート--IPv6オプションはIPv6ヘッダーとトランスポート層ヘッダーの間にパケットに位置している別々のヘッダーに置かれます。 ほとんどのIPv6オプションヘッダーがパケットの配送経路に沿ってどんなルータによっても最終的な目的地に到着するまで調べられもしませんし、処理もされないので、オプションを含んでいて、この組織はパケットのためにルータ性能で全面的な改良を容易にします。 別の改良はIPv6オプションがIPv4と異なって、任意の長さがあって、40バイトに制限できないということです。 それらが使用される処理許可証IPv6オプションであるこの特徴と方法は機能します(IPv4で実用的ではありませんでした)。
A key extensibility feature of IPv6 is the ability to encode,
within an option, the action which a router or host should perform
if the option is unknown. This permits the incremental deployment
of additional functionality into an operational network with a
minimal danger of disruption.
IPv6の主要な伸展性機能はコード化する能力です、オプションの中で、オプションが未知であるならルータかホストが実行するべきである動作。 これは分裂という最小量の危険で追加機能性の増加の展開を操作上のネットワークに可能にします。
* support for authentication and privacy - IPv6 includes the
definition of an extension which provides support for
authentication and data integrity. This extension is included as a
basic element of IPv6 and support for it will be required in all
implementations.
* 認証とプライバシーのサポート--IPv6は認証とデータ保全のサポートを提供する拡大の定義を含んでいます。 それのIPv6とサポートの基本要素がすべての実装で必要であるようにこの拡大は含まれています。
IPv6 also includes the definition of an extension to support
confidentiality by means of encryption. Support for this extension
will be strongly encouraged in all implementations.
また、IPv6は、暗号化によって秘密性をサポートするために拡大の定義を含んでいます。 この拡大のサポートはすべての実装で強く奨励されるでしょう。
Bradner & Mankin [Page 22] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[22ページ]RFC1752推薦
* support for autoconfiguration - IPv6 supports multiple forms of
autoconfiguration, from "plug and play" configuration of node
addresses on an isolated network to the full-featured facilities
offered by DHCP.
* 自動構成のサポート--IPv6は複数のフォームの自動構成をサポートします、孤立しているネットワークに関するノードアドレスの「プラグアンドプレイ」構成から完全装備のDHCPによって提供された施設まで。
* support for source routes - IPv6 includes an extended function
source routing header designed to support the Source Demand Routing
Protocol (SDRP). The purpose of SDRP is to support source-initiated
selection of routes to complement the route selection provided by
existing routing protocols for both inter-domain and intra-domain
routes. [Estrin94b]
* 送信元経路のサポート--IPv6はSource Demandがルート設定プロトコル(SDRP)であるとサポートするように設計された拡張機能ソースルーティングヘッダーを含んでいます。 SDRPの目的は既存のルーティング・プロトコルによって相互ドメインとイントラドメインルートの両方に提供されたルート選択の補足となるようにルートの情報筋によって開始された品揃えをサポートすることです。 [Estrin94b]
* simple and flexible transition from IPv4 - The IPv6 transition plan
is aimed at meeting four basic requirements: [Gillig94a]
* IPv4からの簡単でフレキシブルな変遷--IPv6変遷プランは4つの基本的な要件を満たすのを目的とされます: [Gillig94a]
- Incremental upgrade. Existing installed IPv4 hosts and routers
may be upgraded to IPv6 at any time without being dependent on
any other hosts or routers being upgraded.
- Incremental deployment. New IPv6 hosts and routers can be
installed at any time without any prerequisites.
- Easy Addressing. When existing installed IPv4 hosts or routers
are upgraded to IPv6, they may continue to use their existing
address. They do not need to be assigned new addresses.
- Low start-up costs. Little or no preparation work is needed in
order to upgrade existing IPv4 systems to IPv6, or to deploy new
IPv6 systems.
- 増加のアップグレード。 存在はIPv4ホストをインストールしました、そして、アップグレードするいかなる他のホストかルータにも依存していなくて、ルータはいつでも、IPv6にアップグレードするかもしれません。 - 増加の展開。 いつでも、少しも前提条件なしで新しいIPv6ホストとルータをインストールできます。 - 簡単なアドレシング。 存在がIPv4ホストをインストールしたか、またはルータがIPv6にアップグレードするとき、それらは、それらの既存のアドレスを使用し続けるかもしれません。 新しいアドレスは彼らは割り当てられる必要はありません。 - 低い始動コスト。 準備仕事は、既存のIPv4システムをIPv6にアップグレードさせるか、または新しいIPv6システムを配布するのにまず必要ではありません。
* quality of service capabilities - A new capability is added to
enable the labeling of packets belonging to particular traffic
"flows" for which the sender has requested special handling, such
as non-default quality of service or "real-time" service.
* サービスの質能力--新しい能力は送付者が特別な取り扱いを要求した特定のトラフィック「流れ」に属すパケットのラベリングを可能にするために加えられます、非デフォルトサービスの質や「リアルタイムで」のサービスのように。
Bradner & Mankin [Page 23] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[23ページ]RFC1752推薦
12.1 IPv6 Header Format
12.1 IPv6ヘッダー形式
The IPv6 header, although longer than the IPv4 header, is considerably simplified. A number of functions that were in the IPv4 header have been relocated in extension headers or dropped. [Deering94b]
IPv4ヘッダーより長いのですが、IPv6ヘッダーはかなり簡易型です。 IPv4ヘッダーにあった多くの機能が、拡張ヘッダーを移動するか、または下げられました。 [Deering94b]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| 流れラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ペイロード長| 次のヘッダー| ホップ限界| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + ソースアドレス+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 送付先アドレス+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Version - Internet Protocol version number. IPng has been assigned
version number 6. (4-bit field)
* バージョン--インターネットプロトコルバージョン番号。 バージョンNo.6をIPngに割り当ててあります。 (4ビットの分野)
* Flow Label - This field may be used by a host to label those
packets for which it is requesting special handling by routers
within a network, such as non-default quality of service or "real-
time" service. (28-bit field)
* 流れLabel--この分野はそれがネットワークの中でルータから特別な取り扱いを要求しているそれらのパケットをラベルするのにホストによって使用されるかもしれません、非デフォルトサービスの質か「リアルタイム」サービスなどのように。 (28ビットの分野)
* Payload Length - Length of the remainder of the packet following
the IPv6 header, in octets. To permit payloads of greater than 64K
bytes, if the value in this field is 0 the actual packet length
will be found in an Hop-by-Hop option. (16-bit unsigned integer)
* 有効搭載量Length--八重奏でIPv6ヘッダーに続くパケットの残りの長さ。 64K以上のバイトのペイロードを可能にするために、実際のパケット長はこの分野の値が0であるならホップによるHopオプションで見つけられるでしょう。 (16ビットの符号のない整数)
* Next Header - Identifies the type of header immediately following
the IPv6 header. The Next Header field uses the same values as the
IPv4 Protocol field (8-bit selector field)
* 次のHeader--すぐにIPv6ヘッダーに続いて、ヘッダーのタイプを特定します。 Next Header分野はIPv4プロトコル分野と同じ値を使用します。(8ビットのセレクタ分野)
Bradner & Mankin [Page 24] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[24ページ]RFC1752推薦
* Hop Limit - Used to limit the impact of routing loops. The Hop
Limit field is decremented by 1 by each node that forwards the
packet. The packet is discarded if Hop Limit is decremented to
zero. (8-bit unsigned integer)
* Limitを飛び越してください--ルーティング輪の影響を制限するのにおいて、使用されています。 Hop Limit分野はパケットを進める各ノードで1つ減少します。 Hop Limitがゼロまで減少するなら、パケットは捨てられます。 (8ビットの符号のない整数)
* Source Address - An address of the initial sender of the packet.
(128 bit field)
* ソースAddress--パケットの初期の送付者のアドレス。 (128ビットの分野)
* Destination Address - An address of the intended recipient of the
packet (possibly not the ultimate recipient, if an optional Routing
Header is present). (128 bit field)
* 目的地Address--パケット(ことによるといずれの究極の受取人、任意のルート設定であるなら、Headerは存在していない)の意図している受取人のアドレス。 (128ビットの分野)
12.2 Extension Headers
12.2 拡大ヘッダー
In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport-layer header in a packet. There are a small number of such extension headers, each identified by a distinct Next Header value. [From a number of the documents listed in Appendix C.]
IPv6では、任意のインターネット層の情報はパケットにIPv6ヘッダーとトランスポート層ヘッダーの間に置かれるかもしれない別々のヘッダーでコード化されます。 それぞれが、異なったNext Header値で少ない数のそのような拡張ヘッダーがいるのを特定しました。 [Appendix C.にリストアップされた多くのドキュメントからの]
12.2.1 Hop-by-Hop Option Header
12.2.1 ホップごとのオプションヘッダー
The Hop-by-Hop Options header is used to carry optional
information that must be examined by every node along a packet's
delivery path. The Hop-by-Hop Options header is identified by a
Next Header value of 0 in the IPv6 header, and has the following
format:
ホップによるHop Optionsヘッダーは、パケットの配送経路に沿ってあらゆるノードで調べなければならない任意の情報を運ぶのに使用されます。 ホップによるHop Optionsヘッダーは、IPv6ヘッダーの0のNext Header値によって特定されて、以下の形式を持っています:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー| Hdr Extレン| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Header - Identifies the type of header immediately
following the Hop-by-Hop Options header. Uses the same values
as the IPv4 Protocol field. (8-bit selector)
* 次のHeader--すぐにホップによるHop Optionsヘッダーに続いて、ヘッダーのタイプを特定します。 IPv4プロトコルと同じ値がさばく用途。 (8ビットのセレクタ)
* Hdr Ext Len - Length of the Hop-by-Hop Options header in 8-octet
units, not including the first 8 octets. (8-bit unsigned
integer)
* Hdr Extレン--最初の8つの八重奏を含まない8八重奏のユニットのホップによるHop Optionsヘッダーの長さ。 (8ビットの符号のない整数)
Bradner & Mankin [Page 25] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[25ページ]RFC1752推薦
* Options - Contains one or more TLV-encoded options. (Variable-
length field, of length such that the complete Hop-by-Hop
Options header is an integer multiple of 8 octets long.)
* オプション--1つ以上のTLVによってコード化されたオプションを含んでいます。 (可変長さの分野、長さでは、Hopが跳んでいる完全なOptionsヘッダーが8つの八重奏の整数倍数であるようにものが切望される、)
12.2.2 IPv6 Header Options
12.2.2 IPv6ヘッダーオプション
Two of the currently-defined extension headers -- the Hop-by-Hop
Options header and the End-to-End Options header -- may carry a
variable number of Type-Length-Value (TLV) encoded "options", of
the following format:
2人の現在定義された拡張ヘッダー(ホップによるHop OptionsヘッダーとEndから終わりへのOptionsヘッダー)が以下の形式の可変数のType長さの価値(TLV)のコード化された「オプション」を運ぶかもしれません:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | オプションタイプ| Dataレンを選んでください。| データ+++++++++++++++++をゆだねてください、-、--、--、--、--、--、--、--、-
* Option Type - identifier of the type of option (8-bit field)
* オプションType--オプションのタイプに関する識別子(8ビットの分野)
* Opt Data Len - Length of the Option Data field of this option,
in octets. (8-bit unsigned integer)
* Dataレンを選んでください--八重奏における、このオプションのOption Data分野の長さ。 (8ビットの符号のない整数)
* Option Data - Option-Type-specific data. (Variable-length field)
* Dataにゆだねてください--オプションタイプ詳細データ。 (可変長の分野)
The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if
the processing IPv6 node does not recognize the Option Type:
Option Type識別子が内部的にコード化されるので、それらの最も高いオーダー2ビットは処理IPv6ノードがOption Typeを認識しないなら取らなければならない行動を指定します:
00 - skip over this option and continue processing the header
01 - discard the packet
10 - discard the packet and send an ICMP Unrecognized Type message
to the packet's Source Address, pointing to the unrecognized
Option Type
11 - undefined.
00--このオプションを飛ばして、ヘッダー01を処理し続けています--パケット10を捨ててください--認識されていないOption Type11を示して、ICMP Unrecognized TypeメッセージをパケットのSource Addressに送ってください--パケットを捨ててください、そして、未定義です。
In the case of Hop-by-Hop options only, the third-highest-order
bit of the Option Type specifies whether or not the Option Data of
this option shall be included in the integrity assurance
computation performed when an Authentication header is present.
Option data that changes en route must be excluded from that
computation.
ホップによるHopオプションだけの場合では、Option Typeの3番目の最上位ビットは、このオプションのOption DataがAuthenticationヘッダーが出席しているとき実行された保全保証計算に含まれるかどうか指定します。 その計算から途中で変化するオプションデータを除かなければなりません。
Bradner & Mankin [Page 26] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[26ページ]RFC1752推薦
12.2.3 Routing Header
12.2.3 ルート設定ヘッダー
The Routing header is used by an IPv6 source to list one or more
intermediate nodes (or topological clusters) to be "visited" on
the way to a packet's destination. This particular form of the
Routing Header is designed to support SDRP. [Estrin94b]
ルート設定ヘッダーは、パケットの目的地への途中を「訪問される」ために、1つ以上の中間的ノード(または、位相的なクラスタ)をリストアップするのにIPv6ソースによって使用されます。 ルート設定Headerのこの特定のフォームは、SDRPをサポートするように設計されています。 [Estrin94b]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header |Routing Type=1 |M|F| Reserved | SrcRouteLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NextHopPtr | Strict/Loose Bit Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Source Route .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー|ルート設定タイプ=1|M|F| 予約されます。| SrcRouteLen| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NextHopPtr| 厳しいかゆるいビットマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . ソースルート…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Header - Identifies the type of header immediately
following the Routing Header. Uses the same values as the IPv4
Protocol field. (8-bit selector)
* 次のHeader--すぐにルート設定Headerに続いて、ヘッダーのタイプを特定します。 IPv4プロトコルと同じ値がさばく用途。 (8ビットのセレクタ)
* Routing Type - Indicates the type of routing supported by this
header. Value must be 1.
* ルート設定Type--このヘッダーによってサポートされたルーティングのタイプを示します。 値は1でなければなりません。
* MRE flag - Must Report Errors. If this bit is set to 1, and a
router can not further forward a packet (with an incompletely
traversed source route), as specified in the Source Route, the
router must generate an ICMP error message. If this bit is set
to 0, and a router can not further forward a packet (with an
incompletely traversed source route), as specified in the Source
Route, the router should not generate an ICMP error message.
* MREは弛みます--Report Errorsはそうしなければなりません。 このビットが1に設定されて、ルータが前方に、パケット(不完全に横断された送信元経路がある)を促進できないなら、Source Routeで指定されるように、ルータはICMPエラーメッセージを生成しなければなりません。 このビットが0に設定されて、ルータが前方に、パケット(不完全に横断された送信元経路がある)を促進できないなら、Source Routeで指定されるように、ルータはICMPエラーメッセージを生成するべきではありません。
* F flag - Failure of Source Route Behavior. If this bit it set
to 1, it indicates that if a router can not further forward a
packet (with an incompletely traversed source route), as
specified in the Source Route, the router must set the value of
the Next Hop Pointer field to the value of the Source Route
Length field, so that the subsequent forwarding will be based
solely on the destination address. If this bit is set to 0, it
indicates that if a router can not further forward a packet
(with an incompletely traversed source route), as specified in
the Source Route, the router must discard the packet.
* F旗--Source Route Behaviorの失敗。 これに噛み付いたなら、1にセットして、ルータがSource Routeで指定されるように前方に、パケット(不完全に横断された送信元経路がある)を促進できないなら、ルータがSource Route Length分野の値にNext Hop Pointer分野の値を設定しなければならないのを示します、その後の推進が唯一送付先アドレスに基づくように。 このビットが0に設定されるなら、それは、ルータがSource Routeで指定されるように前方に、パケット(不完全に横断された送信元経路がある)を促進できないなら、ルータがパケットを捨てなければならないのを示します。
Bradner & Mankin [Page 27] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[27ページ]RFC1752推薦
* Reserved - Initialized to zero for transmission; ignored on
reception.
* 予約されました--トランスミッションのためにゼロに初期化されます。 レセプションでは、無視されます。
* SrcRouteLen - Source Route Length - Number of source route
elements/hops in the SDRP Routing header. Length of SDRP
routing header can be calculated from this value (length =
SrcRouteLen * 16 + 8) This field may not exceed a value of 24.
(8 bit unsigned integer)
* SrcRouteLen--ソースRoute Length--ソースの数はSDRPルート設定ヘッダーで要素/ホップを発送します。 SDRPルーティングヘッダーの長さはこの値(長さはSrcRouteLen*16+8と等しい)から計算されて、この分野が24の値を超えないかもしれないということであるかもしれません。 (8の噛み付いている符号のない整数)
* NextHopPtr - Next Hop Pointer- Index of next element/hop to be
processed; initialized to 0 to point to first element/hop in the
source route. When Next Hop Pointer is equal to Source Route
Length then the Source Route is completed. (8 bit unsigned
integer)
* NextHopPtr--次の処理されるべき要素/ホップの次のHop Pointerインデックス。 送信元経路に最初の要素/ホップを示すために0に初期化されます。 Next Hop Pointerがその時Source Route Lengthと等しいときに、Source Routeは完成します。 (8の噛み付いている符号のない整数)
* Strict/Loose Bit Mask - The Strict/Loose Bit Mask is used when
making a forwarding decision. If the value of the Next Hop
Pointer field is N, and the N-th bit in the Strict/Loose Bit
Mask field is set to 1, it indicates that the next hop is a
Strict Source Route Hop. If this bit is set to 0, it indicates
that the next hop is a Loose Source Route Hop. (24 bit
bitpattern)
* 厳しいかゆるいBit Mask--推進決定をするとき、Strict/ゆるいBit Maskは使用されています。 Next Hop Pointer分野の値がNであり、Strict/ゆるいBit Mask分野におけるN番目のビットが1に設定されるなら、それは、次のホップがStrict Source Route Hopであることを示します。 このビットが0に設定されるなら、それは、次のホップがLoose Source Route Hopであることを示します。 (24ビットのbitpattern)
* Source Route - A list of IPv6 addresses indicating the path that
this packet should follow. A Source Route can contain an
arbitrary intermix of unicast and cluster addresses. (integral
multiple of 128 bits)
* ソースRoute--IPv6のリストは、表示がこのパケットがいうことになるはずである経路であると扱います。 Source Routeが含むことができる、任意である、ユニキャストとクラスタアドレスを混ぜてください。 (128ビットの不可欠の倍数)
12.2.4 Fragment Header
12.2.4 断片ヘッダー
The Fragment header is used by an IPv6 source to send payloads
larger than would fit in the path MTU to their destinations.
(Note: unlike IPv4, fragmentation in IPv6 is performed only by
source nodes, not by routers along a packet's delivery path) The
Fragment header is identified by a Next Header value of 44 in the
immediately preceding header, and has the following format:
Fragmentヘッダーは、それらの目的地に経路MTUをうまくはめ込むだろうより大きいペイロードを送るのにIPv6ソースによって使用されます。 (IPv4と異なって以下に注意してください、そして、IPv6での断片化はパケットの配送経路に沿ったルータによって実行されるのではなく、ソースノードだけによって実行されます) Fragmentヘッダーは、すぐに前のヘッダーの44のNext Header値によって特定されて、以下の形式を持っています:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー| 予約されます。| 断片オフセット|Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Header - Identifies the type of header immediately
following the Fragment header. Uses the same values as the IPv4
Protocol field. (8 bit selector)
* 次のHeader--すぐにFragmentヘッダーに続いて、ヘッダーのタイプを特定します。 IPv4プロトコルと同じ値がさばく用途。 (8ビットのセレクタ)
Bradner & Mankin [Page 28] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[28ページ]RFC1752推薦
* Reserved, Res - Initialized to zero for transmission; ignored on
reception.
* Res、予約されました--トランスミッションのためにゼロに初期化されます。 レセプションでは、無視されます。
* Fragment Offset - The offset, in 8-octet units, of the following
payload, relative to the start of the original, unfragmented
payload. (13-bit unsigned integer)
* Offsetを断片化してください--オリジナルの、そして、非断片化しているペイロードの始まりに比例した以下のペイロードの8八重奏の単位におけるオフセット。 (13ビットの符号のない整数)
* M flag - 1 = more fragments; 0 = last fragment.
* Mは弛みます--1は、より多くの断片と等しいです。 0は最後の断片と等しいです。
* Identification - A value assigned to the original payload that
is different than that of any other fragmented payload sent
recently with the same IPv6 Source Address, IPv6 Destination
Address, and Fragment Next Header value. (If a Routing header
is present, the IPv6 Destination Address is that of the final
destination.) The Identification value is carried in the
Fragment header of all of the original payload's fragments, and
is used by the destination to identify all fragments belonging
to the same original payload. (32 bit field)
* 識別--いかなる他のものもペイロードを断片化したより異なった元のペイロードに割り当てられた値は最近、同じIPv6 Source Address、IPv6 Destination Address、およびFragment Next Header値と共に発信しました。 (ルート設定ヘッダーが出席しているなら、IPv6 Destination Addressは最終的な目的地のものです。) Identification値は元のペイロードの断片のすべてのFragmentヘッダーで運ばれて、目的地によって使用されて、同じ元のペイロードに属すすべての断片を特定します。 (32ビットの分野)
12.2.5 Authentication Header
12.2.5 認証ヘッダー
The Authentication header is used to provide authentication and
integrity assurance for IPv6 packets. Non-repudiation may be
provided by an authentication algorithm used with the
Authentication header, but it is not provided with all
authentication algorithms that might be used with this header.
The Authentication header is identified by a Next Header value of
51 in the immediately preceding header, and has the following
format:
Authenticationヘッダーは、IPv6パケットのための認証と保全保証を提供するのに使用されます。 Authenticationヘッダーと共に使用される認証アルゴリズムで非拒否を提供するかもしれませんが、このヘッダーと共に使用されるかもしれないすべての認証アルゴリズムをそれに提供しません。 Authenticationヘッダーは、すぐに前のヘッダーの51のNext Header値によって特定されて、以下の形式を持っています:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Auth Data Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Authentication Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー| Auth Dataレン| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セキュリティ協会ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 認証データ…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Header - Identifies the type of header immediately
following the Authentication header. Uses the same values as
the IPv4 Protocol field. (8-bit selector)
* 次のHeader--すぐにAuthenticationヘッダーに続いて、ヘッダーのタイプを特定します。 IPv4プロトコルと同じ値がさばく用途。 (8ビットのセレクタ)
* Auth Data Len - Length of the Authentication Data field in 8-
octet units. (8-bit unsigned integer)
* Auth Dataレン--8八重奏ユニットのAuthentication Data分野の長さ。 (8ビットの符号のない整数)
Bradner & Mankin [Page 29] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[29ページ]RFC1752推薦
* Reserved - Initialized to zero for transmission; ignored on
reception.
* 予約されました--トランスミッションのためにゼロに初期化されます。 レセプションでは、無視されます。
* Security Assoc. ID - When combined with the IPv6 Source Address,
identifies to the receiver(s) the pre-established security
association to which this packet belongs. (32 bit field)
* セキュリティAssoc。 ID--受信機へのこのパケットが属するプレ設立されたセキュリティ協会は、いつがIPv6 Source Addressに結合したかを特定します。 (32ビットの分野)
* Authentication Data - Algorithm-specific information required
to authenticate the source of the packet and assure its
integrity, as specified for the pre-established security
association. (Variable-length field, an integer multiple of 8
octets long.)
* 認証Data--アルゴリズム特殊情報がパケットの源を認証して、保全を保証するのが必要です、プレ設立されたセキュリティ協会に指定されるように。 (可変長の分野、8つの八重奏の整数倍数は切望されます。)
12.2.6 Privacy Header
12.2.6 プライバシーヘッダー
The Privacy Header seeks to provide confidentiality and integrity
by encrypting data to be protected and placing the encrypted data
in the data portion of the Privacy Header. Either a transport-
layer (e.g., UDP or TCP) frame may be encrypted or an entire IPv6
datagram may be encrypted, depending on the user's security
requirements. This encapsulating approach is necessary to provide
confidentiality for the entire original datagram. If present, the
Privacy Header is always the last non-encrypted field in a packet.
Privacy Headerは、Privacy Headerのデータ部に保護されるためにデータを暗号化して、暗号化されたデータを置くことによって、秘密性と保全を提供しようとします。 輸送層(例えば、UDPかTCP)のフレームが暗号化されるかもしれませんか、または全体のIPv6データグラムは暗号化されるかもしれません、ユーザのセキュリティ要件によって。 この要約アプローチが、全体のオリジナルのデータグラムに秘密性を供給するのに必要です。 存在しているなら、いつもPrivacy Headerはパケットで最後の非暗号化された分野です。
The Privacy Header works between hosts, between a host and a
security gateway, or between security gateways. This support for
security gateways permits trustworthy networks to exist without
the performance and monetary costs of security, while providing
security for traffic transiting untrustworthy network segments.
Privacy Headerはホストの間、または、ホストとセキュリティゲートウェイの間、または、セキュリティゲートウェイの間で働いています。 セキュリティゲートウェイのこのサポートは、信頼できないネットワークセグメントを通過しながらセキュリティをトラフィックに提供している間、信頼できるネットワークがセキュリティの性能と通貨のコストなしで存在することを許可します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association Identifier (SAID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Initialization Vector .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header* | Length* | Reserved* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Protected Data* +-+-+-+-+-+-+-+-+-+-+
| | trailer* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セキュリティ協会識別子(言われています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . 初期設定ベクトル。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー*| 長さ*| 予約された*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 保護されたデータ*+++++++++++| | トレーラ*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*encrypted
*暗号化されます。
Bradner & Mankin [Page 30] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[30ページ]RFC1752推薦
* Security Association Identifier (SAID) - Identifies the security
association for this datagram. If no security association has
been established, the value of this field shall be 0x0000. A
security association is normally one-way. An authenticated
communications session between two hosts will normally have two
SAIDs in use (one in each direction). The receiving host uses
the combination of SAID value and originating address to
distinguish the correct association. (32 bit value)
* セキュリティAssociation Identifier(サイード)--このデータグラムのためにセキュリティ協会を特定します。 セキュリティ協会が全く設立されていないと、この分野の値は0×0000になるでしょう。 通常、セキュリティ協会は一方向です。 通常、2人のホストの間の認証されたコミュニケーションセッションには使用中の2SAIDsがある、(あるコネ、各方向) 受信ホストは、正しい協会を区別するのにサイード値と起因するアドレスの組み合わせを使用します。 (32ビットの値)
* Initialization Vector - This field is optional and its value
depends on the SAID in use. For example, the field may contain
cryptographic synchronization data for a block oriented
encryption algorithm. It may also be used to contain a
cryptographic initialization vector. A Privacy Header
implementation will normally use the SAID value to determine
whether this field is present and, if it is, the field's size
and use. (presence and length dependent on SAID)
* 初期設定Vector--この分野は任意であり、値は使用中のサイードに頼っています。 例えば、分野はブロックの指向の暗号化アルゴリズムのための暗号の同期データを含むかもしれません。 また、それは、暗号の初期化ベクトルを含むのに使用されるかもしれません。 通常、Privacy Header実装はそれがそうであることのフィールドのこの分野が存在しているか否かに関係なく、決定するサイード値、サイズ、および使用を使用するでしょう。 (サイードに依存する存在と長さ)
* Next Header - encrypted - Identifies the type of header
immediately following the Privacy header. Uses the same values
as the IPv4 Protocol field. (8 bit selector)
* すぐにPrivacyヘッダーに続いて、次のHeader(暗号化されている)はヘッダーのタイプを特定します。 IPv4プロトコルと同じ値がさばく用途。 (8ビットのセレクタ)
* Reserved - encrypted - Ignored on reception.
* 予約されました--レセプションで無視されて、暗号化されます。
* Length - encrypted - Length of the Privacy Header in 8-octet
units, not including the first 8 octets. (8-bit unsigned
integer)
* 長さ(暗号化される)は最初の8つの八重奏を含まない8八重奏のユニットの長さのPrivacy Headerです。 (8ビットの符号のない整数)
* Protected Data - encrypted - This field may contain an entire
encapsulated IPv6 datagram, including the IPv6 header, a
sequence of zero or more IPv6 options, and a transport-layer
payload, or it may just be a sequence of zero or more IPv6
options followed by a transport-layer payload. (variable
length)
* 全体のカプセル化されたIPv6データグラムを含んでいて、IPv6ヘッダー、ゼロの系列を含んでいて、この分野がそうするかもしれないか、または、より多くのIPv6がゆだねる保護されたData(暗号化される)と、トランスポート層ペイロードか、それはそうするかもしれません。ただゼロの順序かトランスポート層ペイロードがいうことになったより多くのIPv6オプションになってください。 (可変長)
* trailer (Algorithm-dependent Trailer) - encrypted - A field
present to support some algorithms which need to have padding
(e.g., to a full cryptographic block size for block-oriented
encryption algorithms) or for storage of authentication data for
use with a encryption algorithm that provides confidentiality
without authentication. It is present only when the algorithm
in use requires such a field. (presence and length dependent on
SAID)
* 分野が詰め物(例えば、ブロック指向の暗号化アルゴリズムのための完全な暗号のブロック・サイズへの)を必要とするいくつかのアルゴリズムをサポートするか、または使用のための認証データのストレージのために認証なしで秘密性を提供する暗号化アルゴリズムで贈るトレーラ(アルゴリズム依存するTrailer)(暗号化されます)。 使用中のアルゴリズムがそのような分野を必要とするときだけ、それは存在しています。 (サイードに依存する存在と長さ)
Bradner & Mankin [Page 31] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[31ページ]RFC1752推薦
12.2.7 End-to-End Option Header
12.2.7 終わりから終わりへのオプションヘッダー
The End-to-End Options header is used to carry optional
information that needs to be examined only by a packet's
destination node(s). The End-to-End Options header is identified
by a Next Header value of TBD in the immediately preceding header,
and has the same format as the Hop-by-Hop Option Header except for
the ability to exclude an option from the authentication integrity
assurance computation.
Endから終わりへのOptionsヘッダーは、パケットの目的地ノードだけによって調べられる必要がある任意の情報を運ぶのに使用されます。 Endから終わりへのOptionsヘッダーは、すぐに前のヘッダーのTBDのNext Header値によって特定されて、認証保全保証計算にオプションを入れないようにする能力以外のホップによるHop Option Headerと同じ形式を持っています。
13. IPng Working Group
13. IPng作業部会
We recommend that a new IPng Working Group be formed to produce specifications for the core functionality of the IPv6 protocol suite. The working group will carry out the recommendations of the IPng Area Directors as outlined at the July 1994 IETF and in this memo. We recommend that this working group be chaired by Steve Deering of Xerox PARC and Ross Callon of Wellfleet.
私たちは、新しいIPng作業部会がIPv6プロトコル群に関する中心となる機能性のための仕様を作り出すために形成されることを勧めます。 ワーキンググループは1994年7月のIETFにおいてこのメモに概説されているようにIPng Areaディレクターの推薦を行うでしょう。 私たちは、このワーキンググループがゼロックスPARCのスティーブ・デアリングとWellfleetのロスCallonによってまとめられることを勧めます。
The primary task of the working group is to produce a set of documents that define the basic functions, interactions, assumptions, and packet formats for IPv6. We recommend that Robert Hinden of Sun Microsystems be the editor for these documents. The documents listed in Appendix C will be used by the working group to form the basis of the final document set.
ワーキンググループのプライマリタスクはIPv6のために基本機能、相互作用、仮定、およびパケット・フォーマットを定義する1セットのドキュメントを製作することです。 私たちは、サン・マイクロシステムズのロバートHindenがこれらのドキュメントのためのエディタであることを推薦します。 Appendix Cにリストアップされたドキュメントは、最終合意文書セットの基礎を形成するのにワーキンググループによって使用されるでしょう。
The work of the IPng Working Group includes:
IPng作業部会の仕事は:
* complete the IPv6 overview document
* complete the IPv6 detailed operational specification
* complete the IPv6 Addressing Architecture specification
* produce specifications for IPv6 encapsulations over various media
* complete specifications for the support of packets larger than 64KB
* complete specifications of the DNS enhancements required to support
IPv6
* complete specification of ICMP, IGMP and router discovery for
support of IPv6.
* complete specification of path MTU discovery for IPv6
* complete specifications of IPv6 in IPv6 tunneling
* complete the suggested address format and assignment plan
* coordinate with the Address Autoconfiguration Working Group
* coordinate with the NGTRANS and TACIT Working Groups
* complete specifications of authentication and privacy support
headers
* 完全な状態でIPv6概要ドキュメント*を完成してください。IPv6の詳細な操作上の仕様*はDNS増進の64KBの*完全な仕様より大きいパケットのサポートのための完全な仕様がIPv6*がIPv6のサポートのためのICMP、IGMP、およびルータ発見の完全な仕様であるとサポートするのを必要とした様々なメディア*の上にIPv6カプセル化のためのIPv6 Addressing Architecture仕様*生産物仕様を完成します。 * IPv6のための*IPv6トンネリング*におけるIPv6の完全な仕様がNGTRANSと共にAddress Autoconfiguration作業部会*座標で提案されたアドレス形式と課題プラン*座標を完成するという経路MTU探索の完全な仕様と認証とプライバシーのTACIT Working Groups*完全な仕様はヘッダーを支えます。
Bradner & Mankin [Page 32] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[32ページ]RFC1752推薦
The working group should also consider a few selected enhancements including:
考えて、:また、ワーキンググループは、いくつかが増進を選択したと考えるべきです。
* consider ways to compress the IPv6 header in the contexts of native
IPv6, multiple IPv6 packets in a flow, and encapsulated IPv6
* consider specifying support for a larger minimum MTU
* 流れでネイティブのIPv6、複数のIPv6パケットの文脈でIPv6ヘッダーを圧縮する方法を考えてください。そうすれば、カプセル化されたIPv6*は、より大きい最小のMTUのサポートを指定すると考えます。
14. IPng Reviewer
14. IPng評論家
Currently it is the task of the IPng Area Directors, the IPng Directorate and the chairs of the proposed ipng working group to coordinate the activities of the many parallel efforts currently directed towards different aspects of IPng. While this is possible and currently seems to be working well it can not be maintained over the long run because, among other reasons, the IPng Area will be dissolved eventually and its Directorate disbanded. It will also become much more difficult as IPng related activities start up in other IETF areas.
現在の、それは現在IPngの異なった局面に向けられている多くの平行な取り組みの活動を調整する提案されたipngワーキンググループのIPng Areaディレクター、IPng Directorate、およびいすに関するタスクです。 結局はIPng Areaが結局他にも理由はあるが溶かされるので、これは、可能であり、現在よく何とかうまくやっているのを維持できないように思えます、そして、Directorateは解散しましたが。 また、IPng関連活動が他のIETF領域で始動するのに応じて、それははるかに難しくなるでしょう。
We recommend that an IPng Reviewer be appointed to be specifically responsible for ensuring that a consistent view of IPv6 is maintained across the related working groups. We feel that this function is required due to the complex nature of the interactions between the parts of the IPng effort and due to the distribution of the IPng related work amongst a number of IETF areas. We recommend that Dave Clark of MIT be offered this appointment.
私たちは、IPng ReviewerがIPv6の一貫した視点が関連するワーキンググループの向こう側に維持されるのを確実にするのに明確に責任があるように任命されることを勧めます。 私たちは、この機能がIPng取り組みの部品とIPngの関連する仕事の分配のため相互作用の複雑な自然のため多くのIETF領域の中で必要であると感じます。 私たちは、このアポイントメントがMITのデーブ・クラークに提供されることを勧めます。
This would be a long-term task involving the review of on-going activities. The aim is not for the IPng Reviewer to make architectural decisions since that is the work of the various working groups, the IAB, and the IETF as a whole.. The aim is to spot gaps or misunderstandings before they reach the point where functionality or interworkability is threatened.
これは継続している活動のレビューにかかわる長期のタスクでしょう。 目的は全体でそれが様々なワーキンググループの仕事であるので建築決定をするIPng Reviewer、IAB、およびIETFのためのものではありません。 目的は機能性かinterworkabilityが脅かされるポイントに達する前にギャップか誤解を見つけることです。
15. Address Autoconfiguration
15. アドレス自動構成
As data networks become more complex the need to be able to bypass at least some of the complexity and move towards "plug and play" becomes ever more acute. The user can not be expected to be able to understand the details of the network architecture or know how to configure the network software in their host. In the ideal case, a user should be able to unpack a new computer, plug it into the local network and "just" have it work without requiring the entering of any special information. Security concerns may restrict the ability to offer this level of transparent address autoconfiguration in some environments but the mechanisms must be in place to support whatever level of automation which the local environment feels comfortable with.
データ網が、より複雑になるのに従って、少なくとも複雑さのいくつかを迂回させて、「プラグアンドプレイ」に近づくことができる必要性は深刻になります。 ネットワークアーキテクチャの詳細を理解しているか、または彼らのホストでネットワークソフトウェアを構成する方法を知ることができることをユーザを期待できません。 理想的な場合では、どんな特別な情報も入ることを必要としないで、ユーザは、新しいコンピュータをアンパックして、企業内情報通信網にそれのプラグを差し込んで、「ちょっと」それを働かせることができるべきです。 安全上の配慮はいくつかの環境における、このレベルの透明なアドレス自動構成を提供する能力を制限するかもしれませんが、地方の環境が気持ちが良いいかなるレベルのオートメーションもサポートするために、メカニズムは適所にあるに違いありません。
Bradner & Mankin [Page 33] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[33ページ]RFC1752推薦
The basic requirement of "plug and play" operation is that a host must be able to acquire an address dynamically, either when attaching to a network for the first time or when the host needs to be readdressed because the host moved or because the identity of the network has changed. There are many other functions required to support a full "plug and play" environment. [Berk94] Most of these must be addressed outside of the IPv6 Area but a focused effort to define a host address autoconfiguration protocol is part of the IPv6 process.
「プラグアンドプレイ」操作に関する基本的な要件は初めてかホストが、ホストが移行したか、またはネットワークのアイデンティティが変化したのであて名を書き直される必要があるという場合にネットワークに付くとき、ホストがダイナミックにアドレスを習得できなければならないということです。 完全な「プラグアンドプレイ」が環境であるとサポートするのに必要である他の多くの機能があります。 [Berk94] IPv6 Areaの外でこれらの大部分を扱わなければなりませんが、ホスト・アドレス自動構成プロトコルを定義する集中している取り組みはIPv6プロセスの一部です。
We recommend that a new Address Autoconfiguration Working Group (addrconf) be formed with Dave Katz of Cisco Systems and Sue Thomson of Bellcore as co-chairs. The purpose of this working group is to design and specify a protocol for allocating addresses dynamically to IPv6 hosts. The address configuration protocol must be suitable for a wide range of network topologies, from a simple isolated network to a sophisticated globally connected network. It should also allow for varying levels of administrative control, from completely automated operation to very tight oversight.
私たちは、新しいAddress Autoconfiguration作業部会(addrconf)がシスコシステムズのデーヴ・キャッツとBellcoreのスー・トムソンと共に共同議長として形成されることを勧めます。 このワーキンググループの目的は、ダイナミックにIPv6ホストにアドレスを割り当てるのにプロトコルを設計して、指定することです。 アドレス構成プロトコルはさまざまなネットワークtopologiesに適当であるに違いありません、簡単な孤立しているネットワークから精巧なグローバルに接続されたネットワークまで。 また、それは異なったレベルの完全に自動化された操作から非常にきつい見落としまでの運営管理コントロールを考慮するべきです。
The scope of this working group is to propose a host address autoconfiguration protocol which supports the full range of topological and administrative environments in which IPv6 will be used. It is the intention that, together with IPv6 system discovery, the address autoconfiguration protocol will provide the minimal bootstrapping information necessary to enable hosts to acquire further configuration information (such as that provided by DHCP in IPv4). The scope does not include router configuration or any other host configuration functions. However, it is within the scope of the working group to investigate and document the interactions between this work and related functions including system discovery, DNS autoregistration, service discovery, and broader host configuration issues, to facilitate the smooth integration of these functions. [Katz94a]
このワーキンググループの範囲はIPv6が使用される最大限の範囲の位相的で管理の環境をサポートするホスト・アドレス自動構成プロトコルを提案することになっています。 それはアドレス自動構成プロトコルがIPv6システム発見と共にホストがさらなる設定情報(DHCPによってIPv4に提供されたそれなどの)を取得するのを可能にするのに必要な最小量のブートストラップ法情報を提供するという意志です。 範囲はルータ構成かいかなる他のホスト構成機能も含んでいません。 しかしながら、これらの機能の滑らかな統合を容易にするためにシステム発見、DNS autoregistration、サービス発見、および、より広いホスト構成問題を含んでいて、この仕事と関連する機能の間に相互作用を調査して、記録するために、ワーキンググループの範囲の中にそれはあります。 [Katz94a]
The working group is expected to complete its work around the end of 1994 and disband at that time. The group will use "IPv6 Address Autoconfiguration Architecture" [Katz94b] draft document as the basis of their work.
ワーキンググループは、1994年の終わり頃に仕事を終了して、その時解散すると予想されます。 グループは彼らの仕事の基礎として「IPv6アドレス自動構成アーキテクチャ」[Katz94b]という草稿ドキュメントを使用するでしょう。
16. Transition
16. 変遷
The transition of the Internet from IPv4 to IPv6 has to meet two separate needs. There is a short term need to define specific technologies and methods to transition IPv4 networks, including the Internet, into IPv6 networks and an IPv6 Internet. There is also a long term need to do broad-based operational planning for transition, including developing methods to allow decentralized migration
インターネットのIPv4からIPv6までの変遷は2つの別々の需要を満たさなければなりません。 変遷IPv4ネットワークと独自技術とメソッドを定義する短期間必要があります、インターネットを含んでいて、IPv6ネットワークとIPv6インターネットに。 また、変遷のための広域的な業務計画をする長期必要があります、分散移行を許容するメソッドを開発するのを含んでいて
Bradner & Mankin [Page 34] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[34ページ]RFC1752推薦
strategies, understanding the ramifications of a long period of coexistence when both protocols are part of the basic infrastructure, developing an understanding of the type and scope of architectural and interoperability testing that will be required to ensure a reliable and manageable Internet in the future.
戦略、タイプの理解とそれが建築するのと相互運用性テストであることの範囲を育んで、両方のプロトコルが基本的なインフラストラクチャの一部である共存の長期の分岐を理解するのが将来信頼できて処理しやすいインターネットを確実にするのが必要です。
16.1 Transition - Short Term
16.1変遷--短い期間
Any IPng transition plan must take into account the realities of what types of devices vendors will build and network managers will deploy. The IPng transition plan must define the procedures required to successfully implement the functions which vendors will be likely to include in their devices. This is the case even if there are good arguments to recommend against a particular function, header translation for example. If products will exist it is better to have them interoperate than not.
どんなIPng変遷プランもどんなタイプのデバイスベンダーが建てられるかに関する現実を考慮に入れなければなりません、そして、ネットワークマネージャは展開するでしょう。 IPng変遷プランは首尾よく、ベンダーがそれらのデバイスに含んでいそうである機能を実装するのに必要である手順を定義しなければなりません。 例えば、特定の機能、ヘッダー翻訳に対して推薦する良い議論があっても、これはそうです。 製品が存在するなら、彼らに共同利用させているほうがよいです。
We recommend that a new IPng Transition (NGTRANS) Working Group be formed with Bob Gilligan of Sun Microsystems and xxx of yyy as co- chairs to design the mechanisms and procedures to support the transition of the Internet from IPv4 to IPv6 and to give advice on what procedures and techniques are preferred.
私たちは新しいIPng Transition(NGTRANS)作業部会が共同いすとしてサン・マイクロシステムズのボブ・ギリガンとyyyのxxxで形成されて、インターネットのIPv4からIPv6までの変遷をサポートして、どんな手順とテクニックが好まれるかに関してアドバイスするようにメカニズムと手順を設計することを勧めます。
The work of the group will fall into three areas:
グループの仕事は3つの領域に落ちるでしょう:
* Define the processes by which the Internet will make the transition
from IPv4 to IPv6. As part of this effort, the group will produce
a document explaining to the general Internet community what
mechanisms will be employed in the transition, how the transition
will work, the assumptions about infrastructure deployment inherent
in the operation of these mechanisms, and the types of
functionality that applications developers will be able to assume
as the protocol mix changes over time.
* Define and specify the mandatory and optional mechanisms that
vendors should implement in hosts, routers, and other components of
the Internet in order for the transition to be carried out. Dual-
stack, encapsulation and header translation mechanisms must all be
defined, as well as the interaction between hosts using different
combinations of these mechanisms. The specifications produced will
be used by people implementing these IPv6 systems.
* Articulate a concrete operational plan for the Internet to make the
transition from IPv4 to IPv6. The result of this work will be a
transition plan for the Internet that network operators and
Internet subscribers can execute.
[Gillig94c]
* インターネットがIPv4からIPv6までの変遷をするプロセスを定義してください。 この取り組みの一部として、グループはどんなメカニズムが変遷で使われるかが一般的なインターネットコミュニティにわかるドキュメントを製作するでしょう、変遷がどう働くだろうか、これらのメカニズムの操作に固有のインフラストラクチャ展開に関する仮定、そして、アプリケーション開発者がプロトコルとして仮定できる機能性のタイプが時間がたつにつれて、変化を混ぜます。 * ベンダーがインターネットのホスト、ルータ、および他のコンポーネントで実装するべきである義務的で任意のメカニズムを定義して、指定して、変遷が行われてください。 二元的なスタック、カプセル化、およびヘッダー変換メカニズムをすべて定義しなければなりません、これらのメカニズムの異なった組み合わせを使用しているホストの間の相互作用と同様に。作り出された仕様はこれらのIPv6システムを導入する人々によって使用されるでしょう。*インターネットがIPv4からIPv6までの変遷をする具体的な操作上の計画について明確に話してください。 この仕事の結果はネットワーク・オペレータとインターネット加入者が実行できるインターネットのために変遷プランになるでしょう。 [Gillig94c]
Bradner & Mankin [Page 35] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[35ページ]RFC1752推薦
The working group is expected to complete its work around the end of 1994 and disband at that time. The group will use the "Simple SIPP Transition (SST)" [Gilig94a] overview document as the starting point for its work.
ワーキンググループは、1994年の終わり頃に仕事を終了して、その時解散すると予想されます。 グループは仕事に出発点として「簡単なSIPP変遷(SST)」[Gilig94a]という概要ドキュメントを使用するでしょう。
16.2 Transition - Long Term
16.2変遷--長い期間
There are a number of transition related topics in addition to defining the specific IPv4 to IPv6 mechanisms and their deployment, operation and interaction. The ramifications and procedures of migrating to a new technology or to a new version of an existing technology must be fully understood.
IPv6メカニズム、彼らの展開、操作、および相互作用と特定のIPv4を定義することに加えて多くの変遷関連した話題がいます。 既存の技術が新技術、または、新しいバージョンに移行する分岐と手順を完全に理解しなければなりません。
We recommend that the Transition and Coexistence Including Testing (TACIT) Working Group, which was started a few months ago, explore some of the basic issues associated with the deployment of new technology into an established Internet. The TACIT Working Group will focus on the generic issues of transition and will not limit itself to the upcoming transition to IPv6 because, over time, enhancements to IPv6 (IPv6ng) will be developed and accepted. At that point they will need to be deployed into the then existing Internet. The TACIT Working Group will be more operationally oriented than the NGTRANS Working Group and will continue well into the actual IPv6 transition.
私たちは、TransitionとCoexistence Including Testing(TACIT)作業部会(数カ月前に始動された)が新技術の展開に関連している初版のいくつかを確立したインターネットに探ることを勧めます。 TACIT作業部会は、時間がたつにつれてIPv6(IPv6ng)への増進を開発して、受け入れるので、変遷のジェネリック問題に焦点を合わせて、それ自体をIPv6への今度の変遷に制限しないでしょう。 その時、彼らは、当時の既存のインターネットに配布される必要があるでしょう。 TACIT作業部会はNGTRANS作業部会より操作上指向するようになるでしょう、そして、実際のIPv6変遷によく続くでしょう。
The main areas of exploration are:
探検の主な領域は以下の通りです。
* Make the transition from a currently deployed protocol to a new
protocol while accommodating heterogeneity and decentralized
management.
* Since it is often difficult or impossible to replace all legacy
systems or software, it is important to understand the
characteristics and operation of a long period of coexistence
between a new protocol and the existing protocol.
* The Internet must now be considered a utility. We are far removed
from a time when a new technology could be deployed to see if it
would work in large scale situations. Rigorous architectural and
interoperability testing must be part of the predeployment phase of
any proposed software for the Internet. Testing the scaling up
behaviors and robustness of a new protocol will offer particular
challenges. The WG should determine if there are lessons to be
learned from: OSPF, BGP4 and CIDR Deployment, the AppleTalk 1 to 2
transition, DECnet Phase 4 to Phase 5 planning and transition,
among others.
* 異種性と分散管理に対応している間、現在配布しているプロトコルから新しいプロトコルまでの変遷をしてください。 * すべてのレガシーシステムかソフトウェアを置き換えるのがしばしば難しいか、または不可能であるので、新しいプロトコルと既存のプロトコルの間の長期の共存の特性と操作を理解しているのは重要です。 * 現在、ユーティリティであるとインターネットを考えなければなりません。 私たちはそれが大規模状況で働くかどうか確認するために新技術を配布することができた時から遠くに外されます。 建築するのと相互運用性の厳しいテストはインターネットのためのどんな提案されたソフトウェアの前展開フェーズの一部であるに違いありません。 新しいプロトコルの振舞いと丈夫さにスケーリングをテストすると、特定の挑戦は提供されるでしょう。 WGは、以下から学習されるためにレッスンがあるかどうか決定するはずです。 OSPFとBGP4とCIDR DeploymentとAppleTalk1〜2変遷とPhase5計画へのDECnet Phase4と特に変遷。
Bradner & Mankin [Page 36] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[36ページ]RFC1752推薦
The TACIT Working Group will explore each of these facets of the deployment of new technology and develop a number of documents to help guide users and managers of affected data networks and provide to the IETF:
TACIT作業部会は、それぞれの新技術の展開のこれらの一面を探検して、影響を受けるデータ網のユーザとマネージャを誘導して、IETFに供給するのを助けるために多くのドキュメントを開発するでしょう:
* Detailed descriptions of problem areas in transition and
coexistence, both predicted, based on lessons learned, and observed
as the IPv6 process progresses.
* Recommendations for specific testing procedures.
* Recommendations for coexistence operations procedures
* Recommendations for the smoothing of decentralized transition
planning.
[Huston94]
* ともに予測されたレッスンに基づいている変遷と共存における、問題領域の詳述は、学んで、IPv6プロセスが進歩をするので、見ました。 * 特定の試験手順のための推薦。 * 分散移行計画のスムージングのための共存操作手順*推薦のための推薦。 [Huston94]
17. Other Address Families
17. 他のアドレスファミリー
There are many environments in which there are one or more network protocols already deployed or where a significant planning effort has been undertaken to create a comprehensive network addressing plan. In such cases there may be a temptation to integrate IPv6 into the environment by making use of an existing addressing plan to define all or part of the IPv6 addresses. The advantage of doing this is that it permits unified management of address space among multiple protocol families. The use of common addresses can help facilitate transition from other protocols to IPv6.
既に配布された1つ以上のネットワーク・プロトコルがあるか、または重要な計画取り組みが包括的なネットワークアドレシングプランを作成するために引き受けられた多くの環境があります。 そのような場合、IPv6アドレスのすべてか一部を定義する既存のアドレシング計画を利用することによってIPv6を環境と統合する誘惑があるかもしれません。 これをする利点は複数のプロトコルファミリーでアドレス空間の統一された管理を可能にするということです。 一般的なアドレスの使用は、他のプロトコルからIPv6までの変遷を容易にするのを助けることができます。
If the existing addresses are globally unique and assigned with regard to network topology this may be a reasonable idea. The IETF should work with other organizations to develop algorithms that could be used to map addresses between IPv6 and other environments. The goal for any such mapping must be to provide an unambiguous 1 to 1 map between individual addresses.
既存のアドレスがグローバルにユニークでネットワーク形態に関して割り当てられるなら、これは妥当な考えであるかもしれません。 IETFは、IPv6と他の環境の間のアドレスを写像するのに使用できたアルゴリズムを開発するために他の組織と共に働いているはずです。 どんなそのようなマッピングの目標も明白な1〜1つの地図を個々のアドレスの間に提供することでなければなりません。
Suggestions have been made to develop mapping algorithms for Novell IPX addresses, some types of OSI NSAPs, E164 addresses and SNA addresses. Each of these possibilities should be carefully examined to ensure that use of such an algorithm solves more problems than it creates. In some cases it may be better to recommend either that a native IPng addressing plan be developed instead, or that an IPv6 address be used within the non-IP environment. [Carpen94b]
ノベルIPXアドレスのためのアルゴリズム、OSI NSAPsの何人かのタイプ、164Eのアドレス、およびSNAアドレスを写像しながら展開するのを提案をしました。 それぞれのこれらの可能性は、そのようなアルゴリズムの使用が作成するより多くの問題を解決するのを保証するために慎重に調べられるべきです。 いくつかの場合、固有のIPngアドレシングプランが代わりに開発されるか、またはIPv6アドレスが非IP環境の中で使用されることを勧めるほうがよいかもしれません。 [Carpen94b]
We recommend that, in conjunction with other organizations, recommendations about the use of non-IPv6 addresses in IPv6 environments and IPv6 addresses in non-IPv6 environments be developed.
私たちは、他の組織に関連したIPv6環境とIPv6アドレスの非IPv6環境における非IPv6アドレスの使用に関する推薦が開発されることを勧めます。
Bradner & Mankin [Page 37] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[37ページ]RFC1752推薦
18. Impact on Other IETF Standards
18. 他のIETF規格で影響を与えてください。
Many current IETF standards are affected by IPv6. At least 27 of the current 51 full Internet Standards must be revised for IPv6, along with at least 6 of the 20 Draft Standards and at least 25 of the 130 Proposed Standards. [Postel94]
多くの現在のIETF規格がIPv6で影響を受けます。 IPv6のために少なくとも51現在の完全なインターネットStandardsのうち27を改訂しなければなりません、少なくとも20Draft Standardsのうち6と少なくとも130Proposed Standardsのうち25と共に。 [Postel94]
In some cases the revisions consist of simple changes to the text, for example, in a number of RFCs an IP address is referred to in passing as a "32 bit IP address" even though IP addresses are not directly used in the protocol being defined. All of the standards track documents will have to be checked to see if they contain such references.
いくつかの場合、改正はテキストへの簡単な変化から成ります、例えば、多くのRFCsでは、IPアドレスがIPアドレスが定義されるプロトコルでは直接使用されませんが、「32ビットのIPアドレス」として通用する際に参照されます。 標準化過程ドキュメントのすべてが、それらがそのような参照を含むかどうか確認するためにチェックされなければならないでしょう。
In most of the rest of the cases revisions to the protocols, including packet formats, will be required. In many of these cases the address is just being carried as a data element and a revised format with a larger field for the address will have no effect on the functional paradigm.
ケースの残りの大部分では、パケット・フォーマットを含むプロトコルへの改正が必要でしょう。 これらの場合の多くでは、アドレスのための、より大きい分野があるデータ要素と改訂された形式は機能的なパラダイムで効き目がないとき、アドレスがただ運ばれます。
In the remaining cases some facet of the operation of the protocol will be changed as a result of IPv6. For example, the security and source route mechanisms are fundamentally changed from IPv4 with IPv6. Protocols and applications that relied on the IPv4 functionality will have to be redesigned or rethought to use the equivalent function in IPv6.
残っている場合では、IPv6の結果、プロトコルの操作のいくつかの一面を変えるでしょう。 例えば、IPv6と共にIPv4からセキュリティと送信元経路メカニズムを基本的に変えます。 IPv4の機能性を当てにしたプロトコルとアプリケーションは、IPv6で同等な機能を使用するために再設計されなければならないか、または再考されなければならないでしょう。
In a few cases this opportunity should be used to determine if some of the RFCs should be moved to historic, for example EGP [Mills84] and IP over ARCNET. [Provan91]
いくつかの場合では、この機会がいくつかのRFCsが歴史的に動かされるべきであるかどうか決定するのに利用されるべきであり、例えば、EGPはARCNETの上の[Mills84]とIPです。 [Provan91]
The base IPng Working Group will address some of these, existing IETF working groups can work on others, while new working groups must be formed to deal with a few of them. The IPng Working Group will be responsible for defining new versions of ICMP, ARP/RARP, and UDP. It will also review RFC 1639, "FTP Operation Over Big Address Records (FOOBAR)" [Piscit94] and RFC 1191 "Path MTU Discovery" [Mogul90]
IPng作業部会がこれらのいくつかを扱うベース、既存のIETFワーキンググループは他のものに取り組むことができます、それらのいくつかに対処するために新しいワーキンググループを形成しなければなりませんが。 IPng作業部会はICMP、アルプ/RARP、およびUDPの新しいバージョンを定義するのに責任があるでしょう。 また、それはRFC1639、「大きいアドレスの上のFTP操作は(FOOBAR)を記録する」[Piscit94]およびRFC1191「経路MTU発見」を見直すでしょう。[Mogul90]
Existing working groups will examine revisions for some of the routing protocols: RIPv2, IS-IS, IDRP and SDRP. A new working group may be required for OSPF.
既存のワーキンググループはいくつかのルーティング・プロトコルの改正を調べるでしょう: RIPv2、IS-IS、IDRP、およびSDRP。 新しいワーキンググループがOSPFに必要であるかもしれません。
The existing DHCP Working Group may be able to revise DHCP and examine BOOTP.
既存のDHCP作業部会は、DHCPを改訂して、BOOTPを調べることができるかもしれません。
Bradner & Mankin [Page 38] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[38ページ]RFC1752推薦
A TCPng Working Group will be formed soon, and new working groups will have to be formed to deal with standards such as SNMP, DNS, NTP, NETbios, OSI over TCP, Host Requirements, and Kerberos as well as reviewing most of the RFCs that define IP usage over various media.
TCPng作業部会がすぐ、形成されて、新しいワーキンググループは、SNMPや、DNSや、NTPや、NETbiosや、TCPの上のOSIや、Host Requirementsや、ケルベロスなどの規格に対処するために形成されて、様々なメディアの上でIP用法を定義するRFCsの大部分を見直さなければならないでしょう。
In addition to the standards track RFCs mentioned above there are many Informational and Experimental RFCs which would be affected as well as numerous Internet Drafts (and those standards track RFCs that we missed).
前記のように標準化過程RFCsに加えて、多数のインターネットDraftsと同様に影響を受ける多くのInformationalとExperimental RFCsがあります(それらの規格は私たちがいなくて寂しかったRFCsを追跡します)。
We recommend that the IESG commission a review of all standards track RFCs to ensure that a full list of affected documents is compiled. We recommend that the IESG charge current IETF working groups with the task of understanding the impact of IPv6 on their proposals and, where appropriate, revise the documents to include support for IPv6.
私たちは、IESGが、すべての標準化過程RFCsのレビューが、影響を受けるドキュメントに関する完全リストがコンパイルされるのを保証するように任命するのを推薦します。 私たちは、IESGがIPv6の影響を彼らの提案に理解するタスクを現在のIETFワーキンググループに課すことを勧めて、IPv6のサポートを含むように適切であるところでドキュメントを改訂します。
We recommend that the IESG charter new working groups where required to revise other standards RFCs.
私たちは、他の規格RFCsを改訂するのが必要であるところでIESGが新しいワーキンググループをチャーターするのを推薦します。
19. Impact on non-IETF standards and on products
19. 非IETF規格の上と、そして、製品の上に影響を与えてください。
Many products and user applications which rely on the size or structure of IPv4 addresses will need to be modified to work with IPv6. While the IETF can facilitate an investigation of the impacts of IPv6 on non-IETF standards and products, the primary responsibility for doing so resides in the other standards bodies and the vendors.
IPv4アドレスのサイズか構造を当てにする多くの製品とユーザアプリケーションは、IPv6と共に働くように変更される必要があるでしょう。 IETFは非IETF規格と製品におけるIPv6の影響の調査を容易にすることができますが、そうすることへの責務は他の標準化団体とベンダーであります。
Examples of non-IETF standards that are effected by IPv6 include the POSIX standards, Open Software Foundation's DCE and DME, X-Open, Sun ONC, the Andrew File System and MIT's Kerberos. Most products that provide specialized network security including firewall-type devices are among those that must be extended to support IPv6.
IPv6によって作用される非IETF規格に関する例はPOSIX規格、オープン・ソフトウェア協議会のDCE、DME、開いているX、Sun ONC、アンドリューFile System、およびMITのケルベロスを含んでいます。 ファイアウォールタイプデバイスを含む専門化しているネットワークセキュリティを提供するほとんどの製品がIPv6をサポートするために広げなければならないものにあります。
20. APIs
20. API
It is traditional to state that the IETF does not "do" APIs. While there are many reasons for this, the one most commonly referenced is that there are too many environments where TCP/IP is used, too many different operating systems, programming languages, and platforms. The feeling is that the IETF should not get involved in attempting to define a language and operating system independent interface in the face of such complexity.
IETFがAPIを「しない」と述べるのは伝統的です。 この多くの理由がありますが、また、プラットホームTCP/IPが使用されている多くの環境、あまりに多くの異なったオペレーティングシステム、プログラミング言語、および感じがあるものはそのような複雑さに直面して言語とオペレーティングシステムインディペンデント・インタフェースを定義するのを試みるのにIETFにかかわるべきでないということです。
We feel that this historical tendency for the IETF to avoid dealing with APIs should be reexamined in the case of IPv6. We feel that in a few specific cases the prevalence of a particular type of API is such that a single common solution for the modifications made
私たちは、IETFがAPIに対処するのを避けるこの歴史的な傾向がIPv6の場合で再検討されるべきであると感じます。 私たちは、いくつかの特定の場合では、特定のタイプのAPIの普及が変更のためのただ一つの一般的なソリューションが作ったそのようなものであると感じます。
Bradner & Mankin [Page 39] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[39ページ]RFC1752推薦
necessary by IPv6 should be documented.
IPv6が記録されるべきであるのが必要です。
We recommend that Informational RFCs be solicited or developed for these few cases. In particular, the Berkeley-style sockets interface, the UNIX TLI and XTI interfaces, and the WINSOCK interfaces should be targeted. A draft document exists which could be developed into the sockets API description. [Gillig94b]
私たちは、Informational RFCsがこれらのわずかなケースのために請求されるか、または開発されることを勧めます。 特に、バークレー-スタイルソケットインタフェース、UNIX TLI、XTIインタフェース、およびウィンソックインタフェースは狙うべきです。 ソケットAPI記述で開発されることができた草稿ドキュメントは存在しています。 [Gillig94b]
21. Future of the IPng Area and Working Groups
21. IPng領域とワーキンググループの未来
In our presentation at the Houston IETF meeting we stated that the existing IPng proposal working groups would not be forced to close down after the recommendation was made. Each of them has been working on technologies that may have applications in addition to their IPng proposal and these technologies should not be lost.
ヒューストンIETFミーティングにおけるプレゼンテーションでは、私たちは、推薦状をした後に既存のIPng提案ワーキンググループがやむを得ず休業しないと述べました。 それぞれの彼らは彼らのIPng提案に加えたアプリケーションを持っているかもしれない技術に取り組んでいます、そして、これらの技術を失うべきではありません。
Since the Toronto IETF meeting the existing IPng working groups have been returned to the Internet Area. The group members may decide to close down the working groups or to continue some of their efforts. The charters of the working groups must be revised if they choose to continue since they would no longer be proposing an IPng candidate.
以来、既存のIPngワーキンググループと会合するトロントIETFをインターネットAreaに返しています。 グループのメンバーは、ワーキンググループを閉鎖するか、またはそれらの取り組みのいくつかを続けていると決めるかもしれません。 もうIPng候補を提案していないでしょう、したがって、続くのを選ぶなら、ワーキンググループの特許を改訂しなければなりません。
In Toronto the chairs of the SIPP Working Group requested that the SIPP Working Group be concluded. The chairs of the TUBA Working Group requested that the TUBA working group be understood to be in hiatus until a number of the documents in process were completed, at which time they would request that the working group be concluded.
トロントでは、SIPP作業部会のいすが、SIPP作業部会が結論づけられるよう要求しました。 それらが、どの時にワーキンググループが結論づけられるよう要求するだろうかときプロセスの多くのドキュメントが完成するまで、TUBA作業部会のいすは、TUBAワーキンググループが中断にあるのが理解されているよう要求しました。
We recommend that the IPng Area and its Directorate continue until the basic documents have entered the standards track in late 1994 or early 1995 and that after such time the area be dissolved and those IPng Area working groups still active be moved to their normal IETF areas.
私たちは、そのようなものが領域を調節した後に溶かされて、基礎書類が遅い1994か1995年前半に標準化過程に入るまでIPng AreaとそのDirectorateが続き、それらのIPng Areaワーキンググループが能動態を静めることを勧めます。それらの正常なIETF領域に動かされます。
22. Security Considerations
22. セキュリティ問題
The security of the Internet has long been questioned. It has been the topic of much press coverage, many conferences and workshops. Almost all of this attention has been negative, pointing out the many places where the level of possible security is far less than that deemed necessary for the current and future uses of the Internet. A number of the RFC 1550 White Papers specifically pointed out the requirement to improve the level of security available [Adam94, Bell94b, Brit94, Green94, Vecchi94, Flei94] as does "Realizing the Information Future". [Nat94]
インターネットのセキュリティは長い間、質問されています。 それは多くのマスコミ報道、多くの会議、およびワークショップの話題です。 この注意のほとんどすべてが否定的です、可能なセキュリティのレベルがそれよりはるかにインターネットの現在の、そして、将来の用途に必要であることは考えられない多くの場所を指摘して。 多くのRFC1550ホワイトPapersが明確に、「情報未来がわかります」のようにセキュリティの利用可能なレベル[Adam94、Bell94b、Brit94、Green94、Vecchi94、Flei94]を改良するという要件を指摘しました。 [Nat94]
Bradner & Mankin [Page 40] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[40ページ]RFC1752推薦
In February of 1994, the IAB convened a workshop on security in the Internet architecture. The report of this workshop [IAB94] includes an exploration of many of the security problem areas and makes a number of recommendations to improve the level of security that the Internet offers its users.
1994年2月に、IABはインターネットアーキテクチャにおけるセキュリティに関するワークショップを召集しました。 このワークショップ[IAB94]のレポートは、警備上の問題領域の多くの探検を含んで、インターネットがユーザに提供するセキュリティのレベルを改良するという多くの推薦状をします。
We feel that an improvement in the basic level of security in the Internet is vital to its continued success. Users must be able to assume that their exchanges are safe from tampering, diversion and exposure. Organizations that wish to use the Internet to conduct business must be able to have a high level of confidence in the identity of their correspondents and in the security of their communications. The goal is to provide strong protection as a matter of course throughout the Internet.
私たちは、インターネットのセキュリティの基礎水準における改良が継続的な成功に必要であると感じます。 ユーザは、彼らの交換が改ざん、転換、および暴露から安全であると仮定できなければなりません。 業務を行うのにインターネットを使用したがっている組織は彼らの通信員のアイデンティティと彼らのコミュニケーションのセキュリティにおける、高いレベルの信用を持つことができなければなりません。 目標は当然のこととして強い保護をインターネットに提供することです。
As the IAB report points out, many of the necessary tools are not a function of the internetworking layer of the protocol. These higher level tools could make use of strong security features in the internetworking layer if they were present. While we expect that there will be a number of special high-level security packages available for specific Internet constituencies, support for basic packet-level authentication will provide for the adoption of a much needed, widespread, security infrastructure throughout the Internet.
IABがポイントについて結論を提示するとき、必要なツールの多くがプロトコルのインターネットワーキング層の関数ではありません。 それらが存在しているなら、これらのより高い平らなツールはインターネットワーキング層の中で強いセキュリティ機能を利用するかもしれないでしょうに。 私たちが、特定のインターネット選挙民に利用可能な多くの特別なハイレベルのセキュリティパッケージがあると予想している間、基本的なパケット・レベル認証のサポートはインターネット中の多くの必要で、広範囲のセキュリティインフラストラクチャの採用に備えるでしょう。
It is best to separate the support for authentication from the support for encryption. One should be able to use the two functions independently. There are some applications in which authentication of a corespondent is sufficient and others where the data exchanged must be kept private.
暗号化のサポートと認証のサポートを切り離すのは最も十分です。 独自に2つの機能を使用できるべきです。 共同被告の認証が十分であるいくつかの利用と他のものが交換されたデータを個人的に保たなければならないところにいます。
It is our recommendation that IPv6 support packet authentication as a basic and required function. Applications should be able to rely on support for this feature in every IPv6 implementation. Support for a specific authentication algorithm should also be mandated while support for additional algorithms should be optional.
それはIPv6が基本的で必要な機能としてパケット認証をサポートするという私たちの推薦です。 アプリケーションはあらゆるIPv6実装におけるこの特徴のサポートに依存できるべきです。 また、追加アルゴリズムのサポートが任意であるべきである間、特定の認証アルゴリズムのサポートは強制されるべきです。
Thus we recommend that support for the Authentication Header be required in all compliant IPv6 implementations.
したがって、私たちは、Authentication Headerのサポートがすべての対応するIPv6実装で必要であることを推薦します。
We recommend that support for a specific authentication algorithm be required. The specific algorithm should be determined by the time the IPv6 documents are offered as Proposed Standards.
私たちは、特定の認証アルゴリズムのサポートが必要であることを推薦します。 特定のアルゴリズムはProposed StandardsとしてIPv6ドキュメントを提供する時までに決定しているべきです。
We recommend that support for the Privacy Header be required in IPv6 implementations.
私たちは、Privacy HeaderのサポートがIPv6実装で必要であることを推薦します。
Bradner & Mankin [Page 41] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[41ページ]RFC1752推薦
We recommend that support for a privacy authentication algorithm be required. The specific algorithm should be determined by the time the IPv6 documents are offered as Proposed Standards.
私たちは、プライバシー認証アルゴリズムのサポートが必要であることを推薦します。 特定のアルゴリズムはProposed StandardsとしてIPv6ドキュメントを提供する時までに決定しているべきです。
Clearly, a key management infrastructure will be required in order to enable the use of the authentication and encryption headers. However, defining such an infrastructure is outside the scope of the IPv6 effort. We do note that there are on-going IETF activities in this area. The IPv6 transition working groups must coordinate with these activities.
明確に、かぎ管理インフラストラクチャが、認証と暗号化ヘッダーの使用を可能にするのに必要でしょう。 しかしながら、IPv6取り組みの範囲の外にそのようなインフラストラクチャを定義するのがあります。 私たちは、継続しているIETF活動がこの領域にあることに注意します。 IPv6変遷ワーキンググループはこれらの活動で調整されなければなりません。
Just as clearly, the use of authentication and encryption may add to the cost and impact the performance of systems but the more secure infrastructure is worth the penalty. Whatever penalty there is should also decrease in time with improved software and hardware assistance.
ちょうど同じくらい明確に、認証と暗号化の使用は費用と影響にシステムの性能を加えるかもしれませんが、より安全なインフラストラクチャは刑罰の価値があります。 また改良ソフトとハードウェア支援に従ってある刑罰が時間内に減少させるべきであることなら何でも。
The use of firewalls is increasing on the Internet. We hope that the presence of the authentication and privacy features in IPv6 will reduce the need for firewalls, but we do understand that they will continue to be used for the foreseeable future. In this light, we feel that clear guidance should be given to the developers of firewalls on the best ways to design and configure them when working in an IPv6 environment.
ファイアウォールの使用はインターネットで増加しています。 IPv6での認証とプライバシー機能の存在がファイアウォールの必要性を減少させることを願っていますが、私たちは、それらが、予見できる未来に使用され続けるのを理解しています。 この光の中では、私たちは、明確な指導はIPv6環境で働いているとき、それらを設計して、構成する最も良い方法でファイアウォールを開発者に与えられるべきであると感じます。
We recommend that an "IPv6 framework for firewalls" be developed. This framework should explore the ways in which the Authentication Header can be used to strengthen firewall technology and detail how the IPv6 packet should be analyzed by a firewall.
私たちは、「ファイアウォールへのIPv6フレームワーク」が開発されることを勧めます。 このフレームワークは、ファイアウォール技術を強化するのにAuthentication Headerを使用できる方法を探って、IPv6パケットがファイアウォールによってどう分析されるべきであるかを詳しく述べるべきです。
Some aspects of security require additional study. For example, it has been pointed out [Vecchi94] that, even in non-military situations, there are places where procedures to thwart traffic analysis will be required. This could be done by the use of encrypted encapsulation, but this and other similar requirements must be addressed on an on-going basis by the Security Area of the IETF. The design of IPv6 must be flexible enough to support the later addition of such security features.
セキュリティのいくつかの局面が追加研究を必要とします。 例えば、場所がトラヒック分析を阻む手順が必要であるところに非軍事の状況にさえあると指摘されました[Vecchi94]。 暗号化されたカプセル化の使用でこれができるでしょうが、IETFのSecurity Areaは継続ベースでこれと他の同様の要件を扱わなければなりません。 IPv6のデザインはそのようなセキュリティ機能の後の追加をサポートするほどフレキシブルでなければなりません。
We believe that IPv6 with its inherent security features will provide the foundation upon which the Internet can continue to expand its functionality and user base.
私たちは、固有のセキュリティ機能があるIPv6がインターネットがその機能性とユーザベースを膨張させ続けることができる基礎を提供すると信じています。
Bradner & Mankin [Page 42] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[42ページ]RFC1752推薦
23. Authors' Addresses
23. 作者のアドレス
Scott Bradner Harvard University 10 Ware St. Cambridge, MA 02138
スコットブラドナーハーバード大学10は聖ケンブリッジ、MA 02138を用心させます。
Phone: +1 617 495 3864 EMail: sob@harvard.edu
以下に電話をしてください。 +1 3864年の617 495メール: sob@harvard.edu
Allison Mankin USC/Information Sciences Institute 4350 North Fairfax Drive, Suite 400 Arlington, VA 22303
アーリントン、Suite400ヴァージニア 4350年の北のアリソンマンキンUSC/情報科学研究所フェアファクスのドライブ、22303
Phone: +1 703-807-0132 EMail: mankin@isi.edu
以下に電話をしてください。 +1 703-807-0132 メールしてください: mankin@isi.edu
Bradner & Mankin [Page 43] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[43ページ]RFC1752推薦
Appendix A - Summary of Recommendations
付録A--推薦の概要
5.3 Address Assignment Policy Recommendations
changes in address assignment policies are not recommended
reclamation of underutilized assigned addresses is not currently
recommended
efforts to renumber significant portions of the Internet are not
currently recommended
recommend consideration of assigning CIDR-type address blocks out
of unassigned Class A addressees
11. IPng Recommendation
recommend that "Simple Internet Protocol Plus (SIPP) Spec. (128
bit ver)" [Deering94b] be adopted as the basis for IPng
recommend that the documents listed in Appendix C be the basis of
IPng
13. IPng Working Group
recommend that an IPng Working Group be formed, chaired by Steve
Deering and Ross Callon
recommend that Robert Hinden be the document editor for the IPng
effort
14. IPng Reviewer
recommend that an IPng Reviewer be appointed and that Dave Clark
be that reviewer
15. Address Autoconfiguration
recommend that an Address Autoconfiguration Working Group be
formed, chaired by Dave Katz and Sue Thomson
16.1 Transition - Short Term
recommend that an IPng Transition Working Group be formed, chaired
by Bob Gilligan and TBA
16.2 Transition - Long Term
recommend that the Transition and Coexistence Including Testing
Working Group be chartered
17. Other Address Families
recommend that recommendations about the use of non-IPv6 addresses
in IPv6 environments and IPv6 addresses in non-IPv6
environments be developed
18. Impact on Other IETF Standards
recommend the IESG commission a review of all standards track RFCs
recommend the IESG charge current IETF working groups with the
task of understanding the impact of IPng on their proposals
and, where appropriate, revise the documents to include support
for IPng
recommend the IESG charter new working groups where required to
revise other standards RFCs
20. APIs
recommend that Informational RFCs be developed or solicited for a
few of the common APIs
5.3 アドレス課題方針におけるアドレスAssignment Policy Recommendations変化はunderutilized割り当てられたアドレスのお勧めの改善が番号を付け替えさせる現在お勧めの取り組みがあて先ブロックを割り当てられなかったClass A受け取り人11からCIDR-タイプに割り当てる考慮を推薦するというインターネットの重要な部分が現在勧められないことでないということではありません。 IPng Recommendationはその「簡単なインターネットプロトコルと(SIPP)仕様」を推薦します。 (128ビットのver)「[Deering94b] IPngの基礎が、Appendix CにリストアップされたドキュメントがIPng13の基礎であることを推薦するので、採用されてください。」 IPng作業部会は、IPng作業部会がスティーブ・デアリングによって形成されて、まとめられることを勧めます、そして、ロスCallonはロバートHindenがIPng取り組み14のためのドキュメントエディタであることを推薦します。 IPng ReviewerはIPng Reviewerが任命されて、デーブ・クラークがその評論家15であることを推薦します。 アドレスAutoconfigurationは、Address Autoconfiguration作業部会が形成されることを勧めます、デーヴ・キャッツとスートムソン16.1Transitionによってまとめられて--短いTermは、IPng Transition作業部会が形成されることを勧めます、ボブ・ギリガンとTBA16.2Transitionによってまとめられて--長いTermは、TransitionとCoexistence Including Testing作業部会が貸し切りの17であることを推薦します。 他のAddress Familiesは、IPv6環境とIPv6アドレスの非IPv6環境における非IPv6アドレスの使用に関する推薦が18に開発されることを勧めます。 Other IETF Standardsの上の影響は、道のRFCsがIPngの影響を彼らの提案に理解するタスクを現在のIETFワーキンググループに課すことをIESGを勧めるすべての規格のレビューをIESGコミッションに推薦して、適切であるところでIPngが他の規格RFCs20を改訂するのが必要であるところで新しいワーキンググループをチャーターするのをIESGを推薦するサポートを含んでいるドキュメントを改訂します。 APIは、Informational RFCsが一般的なAPIのいくつかのために開発されるか、または請求されることを勧めます。
Bradner & Mankin [Page 44] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[44ページ]RFC1752推薦
21. Future of the IPng Area and Working Groups
recommend that the IPng Area and Area Directorate continue until
main documents are offered as Proposed Standards in late 1994
22. Security Considerations
recommend that support for the Authentication Header be required
recommend that support for a specific authentication algorithm be
required
recommend that support for the Privacy Header be required
recommend that support for a specific privacy algorithm be
required
recommend that an "IPng framework for firewalls" be developed
21. IPng AreaとWorking Groupsの未来は、IPng AreaとArea DirectorateがProposed Standardsとして遅い1994 22で主なドキュメントを提供するまで続くことを勧めます。 セキュリティConsiderationsが、Authentication Headerのサポートが必要であることを推薦する、推薦、特定の認証アルゴリズムのサポートが必要であるのがPrivacy Headerのサポートが必要であることを推薦する、推薦、特定のプライバシーアルゴリズムのサポートが必要であるのが「ファイアウォールへのIPngフレームワーク」が開発されることを勧めます。
Appendix B - IPng Area Directorate
付録B--IPng領域の管理職
J. Allard - Microsoft <jallard@microsoft.com> Steve Bellovin - AT&T <smb@research.att.com> Jim Bound - Digital <bound@zk3.dec.com> Ross Callon - Wellfleet <rcallon@wellfleet.com> Brian Carpenter - CERN <brian.carpenter@cern.ch> Dave Clark - MIT <ddc@lcs.mit.edu > John Curran - NEARNET <curran@nic.near.net> Steve Deering - Xerox <deering@parc.xerox.com> Dino Farinacci - Cisco <dino@cisco.com> Paul Francis - NTT <francis@slab.ntt.jp> Eric Fleischmann - Boeing <ericf@atc.boeing.com> Mark Knopper - Ameritech <mak@aads.com> Greg Minshall - Novell <minshall@wc.novell.com> Rob Ullmann - Lotus <ariel@world.std.com> Lixia Zhang - Xerox <lixia@parc.xerox.com>
J. Allard - Microsoft <jallard@microsoft.com> Steve Bellovin - AT&T <smb@research.att.com> Jim Bound - Digital <bound@zk3.dec.com> Ross Callon - Wellfleet <rcallon@wellfleet.com> Brian Carpenter - CERN <brian.carpenter@cern.ch> Dave Clark - MIT <ddc@lcs.mit.edu > John Curran - NEARNET <curran@nic.near.net> Steve Deering - Xerox <deering@parc.xerox.com> Dino Farinacci - Cisco <dino@cisco.com> Paul Francis - NTT <francis@slab.ntt.jp> Eric Fleischmann - Boeing <ericf@atc.boeing.com> Mark Knopper - Ameritech <mak@aads.com> Greg Minshall - Novell <minshall@wc.novell.com> Rob Ullmann - Lotus <ariel@world.std.com> Lixia Zhang - Xerox <lixia@parc.xerox.com>
Daniel Karrenberg of RIPE joined the Directorate when it was formed but had to withdraw due to the demands of his day job.
RIPEのダニエルKarrenbergはそれが形成されたとき、Directorateを接合しましたが、彼の定職の要求のため引き下がらなければなりませんでした。
Since the Toronto IETF meeting Paul Francis has resigned from the Directorate to pursue other interests. Robert Hinden of Sun Microsystems and Yakov Rekhter of IBM joined.
以来、トロントIETFミーティングポール・フランシスは一身上の都合によりDirectorateを辞職しています。 サン・マイクロシステムズのロバートHindenとIBMのヤコフRekhterは接合しました。
Bradner & Mankin [Page 45] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[45ページ]RFC1752推薦
Appendix C - Documents Referred to the IPng Working Groups
付録C--ドキュメントはIPngワーキンググループについて言及しました。
[Deering94b] Deering, S., "Simple Internet Protocol Plus (SIPP) Spec.
(128 bit ver)", Work in Progress.
[Deering94b] デアリングと、S.と、「簡単なインターネットプロトコルと(SIPP)仕様。」 (128ビットのver)「仕事進行中です」。
[Francis94] Francis, P., "SIPP Addressing Architecture", Work in
Progress.
[Francis94] フランシス、P.、「SIPPアドレッシング体系」が進行中で働いています。
[Rekhter94] Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast
Address Allocation", Work in Progress.
Y.、およびT.李、「IPv6ユニキャストアドレス配分のためのアーキテクチャ」という[Rekhter94]Rekhterは進行中で働いています。
[Gillig94a] Gilligan, R., "Simple SIPP Transition (SST) Overview",
Work in Progress.
[Gillig94a] ギリガン、R.、「簡単なSIPP変遷(SST)概要」が進行中で働いています。
[Gillig94b] Gilligan, R., Govindan, R., Thomson, S., and J. Bound,
"SIPP Program Interfaces for BSD Systems", Work in Progress.
[Gillig94b] ギリガン、R.、Govindan、R.、トムソン、S.、およびJ.バウンド、「BSDシステムのためのSIPPプログラムインタフェース」は進行中で働いています。
[Atkins94a] Atkinson, R., "SIPP Security Architecture", Work in
Progress.
[Atkins94a] アトキンソン、R.、「SIPPセキュリティー体系」が進行中で働いています。
[Atkins94b] Atkinson, R., "SIPP Authentication Header", Work in
Progress.
[Atkins94b] アトキンソン、R.、「SIPP認証ヘッダー」が進行中で働いています。
[Ford94b] Ford, P., Li, T., and Y. Rekhter, "SDRP Routing Header for
SIPP-16", Work in Progress.
[Ford94b] フォード、P.、李、T.、およびY.Rekhter、「SDRPがヘッダーを何SIPP-16インチも発送して、進行中で働いてください。」
[Hinden94c] Hinden, R., "IP Next Generation Overview", Work in
Progress.
R.、「IP次世代概要」という[Hinden94c]Hindenは進行中で働いています。
Appendix D - IPng Proposal Overviews
付録D--IPng提案概要
[Ford94a] Ford, P., and M. Knopper, "TUBA as IPng: A White Paper",
Work in Progress.
[Ford94a] フォード、P.、およびM.Knopper、「IPngとしてのチューバ:」 「白書」、処理中の作業。
[Hinden94a] Hinden, R., "Simple Internet Protocol Plus White Paper",
RFC 1710, Sun Microsystems, October 1994.
[Hinden94a] Hinden、R.、「簡単なインターネットプロトコルプラス白書」、RFC1710、サン・マイクロシステムズ、1994年10月。
[McGovern94] McGovern, M., and R. Ullmann, "CATNIP: Common
Architecture for the Internet", RFC 1707, Sunspot Graphics, Lotus
Development Corp., October 1994.
[McGovern94] マクガヴァン、M.、およびR.ウルマン、「キャットニップ:」 「インターネットへの一般的なアーキテクチャ」、RFC1707、太陽黒点グラフィックス、ロータス・デベロップメント、1994年10月。
Bradner & Mankin [Page 46] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[46ページ]RFC1752推薦
Appendix E - RFC 1550 White Papers
付録E--RFC1550白書
[Adam94] Adamson, B., "Tactical Radio Frequency Communication
Requirements for IPng", RFC 1677, NRL, August 1994.
[Adam94] アダムソン、B.、「IPngのための戦術の無線周波数コミュニケーション要件」、RFC1677、NRL、1994年8月。
[Bello94a] Bellovin, S., "On Many Addresses per Host", RFC 1681, AT&T
Bell Laboratories, August 1994.
[Bello94a]Bellovin、S. 「多くの1ホストあたりのアドレス」のRFC1681、AT&Tベル研究所、1994年8月。
[Bello94b] Bellovin, S., "Security Concerns for IPng", RFC 1675, AT&T
Bell Laboratories, August 1994.
[Bello94b] Bellovin、S.、「IPngのための安全上の配慮」、RFC1675、AT&Tベル研究所、1994年8月。
[Bound94] Bound, J., "IPng BSD Host Implementation Analysis", RFC
1682, Digital Equipment Corporation, August 1994.
[Bound94] バウンド、J.、「IPng BSDホスト導入分析」、RFC1682、ディジタルイクイップメント社、1994年8月。
[Brazd94] Brazdziunas, C., "IPng Support for ATM Services", RFC 1680,
Bellcore, August 1994.
[Brazd94] Brazdziunas、C.、「気圧サービスのIPngサポート」、RFC1680、Bellcore、1994年8月。
[Britt94] Britton, E., and J. Tavs, "IPng Requirements of Large
Corporate Networks", RFC 1678, IBM, August 1994.
[Britt94]ブリトン、E.とJ.Tavs、「大きい企業ネットワークのIPng要件」RFC1678、IBM、1994年8月。
[Brownl94] Brownlee, J., "Accounting Requirements for IPng", RFC
1672, University of Auckland, August 1994.
[Brownl94] ブラウンリー、J.、「IPngのための会計要件」、RFC1672、オークランド大学、1994年8月。
[Carpen94a] Carpenter, B., "IPng White Paper on Transition and Other
Considerations", RFC 1671, CERN, August 1994.
[Carpen94a] 大工、B.、「変遷と他の問題に関するIPng白書」、RFC1671、CERN、1994年8月。
[Chiappa94] Chiappa, N., "IPng Technical Requirements Of the Nimrod
Routing and Addressing Architecture", RFC 1753, December 1994.
[Chiappa94]Chiappa、N.、「ニムロデRoutingとアドレッシング体系に関するIPng技術的要求事項」、RFC1753、1994年12月。
[Clark94] Clark, R., Ammar, M., and K. Calvert, "Multiprotocol
Interoperability In IPng", RFC 1683, Georgia Institute of
Technology, August 1994.
[Clark94]クラークとR.とAmmar、M.とK.カルバート、「IPngのMultiprotocol相互運用性」RFC1683、ジョージア工科大学、1994年8月。
[Curran94] Curran, J., "Market Viability as a IPng Criteria", RFC
1669, BBN, August 1994.
[Curran94] カラン、J.、「IPng評価基準としての市場生存力」、RFC1669、BBN、1994年8月。
[Estrin94a] Estrin, D., Li, T., and Y. Rekhter, "Unified Routing
Requirements for IPng", RFC 1668, USC, cisco Systems, IBM, August
1994.
[Estrin94a]EstrinとD.と李、T.とY.Rekhter、「IPngのための統一されたルート設定要件」RFC1668、USC、コクチマスSystems、IBM(1994年8月)。
[Fleisch94] Fleischman, E., "A Large Corporate User's View of IPng",
RFC 1687, Boeing Computer Services, August 1994.
[Fleisch94] フライシュマン、E.、「大きい企業ユーザーのIPngの視点」、RFC1687、ボーイングのコンピュータサービス、1994年8月。
[Green94] Green, D., Irey, P., Marlow, D., and K. O'Donoghue, "HPN
Working Group Input to the IPng Requirements Solicitation", RFC
1679, NSWC-DD, August 1994.
[Green94] グリーン、D.、Irey、P.、マーロウ、D.、およびK.オダナヒュー、「HPN作業部会は要件懇願をIPngに入力しました」、RFC1679、NSWC-DD、1994年8月。
Bradner & Mankin [Page 47] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[47ページ]RFC1752推薦
[Ghisel94] Ghiselli, A., Salomoni, D., and C. Vistoli, "INFN
Requirements for an IPng", RFC 1676, INFN/CNAF, August 1994.
[Ghisel94]GhiselliとA.とSalomoni、D.とC.Vistoli、「IPngのためのINFN要件」RFC1676、INFN/CNAF、1994年8月。
[Heager94] Heagerty, D., "Input to IPng Engineering Considerations",
RFC 1670, CERN, August 1994.
[Heager94] Heagerty、D.、「IPng工学問題への入力」、RFC1670、CERN、1994年8月。
[Simpson94] Simpson, W. "IPng Mobility Considerations", RFC 1688,
Daydreamer, August 1994.
[Simpson94]シンプソン、W.「IPng移動性問題」、RFC1688、空想家、1994年8月。
[Skelton94] Skelton, R., "Electric Power Research Institute Comments
on IPng", RFC 1673, EPRI, August 1994.
[Skelton94] スケルトン、R.、「IPngの電力研究所のコメント」、RFC1673、EPRI、1994年8月。
[Syming94] Symington, S., Wood, D., and J. Pullen, "Modeling and
Simulation Requirements for IPng", RFC 1667, MITRE, George Mason
University, August 1994.
[Syming94]サイミントンとS.と木、D.とJ.ピューレン、「IPngのためのモデリングシミュレーション要件」RFC1667、斜め継ぎ、ジョージメイスン大学(1994年8月)。
[Taylor94] Taylor, M., "A Cellular Industry View of IPng", RFC 1674,
CDPD Consortium, August 1994.
[Taylor94] テイラー、M.、「IPngのセル企業側の見解」、RFC1674、CDPD共同体、1994年8月。
[Vecchi94] Vecchi, M., "IPng Requirements: A Cable Television
Industry Viewpoint", RFC 1686, Time Warner Cable, August 1994.
[Vecchi94]ヴェッキ、M.、「IPng要件:」 「ケーブルテレビ産業観点」、RFC1686、タイム・ワーナーケーブル、1994年8月。
Appendix F - Additional References
付録F--追加参照
[Almqu92] Almquist, P., "Minutes of the Selection Criteria BOF",
Washington DC IETF, November 1992, (ietf/nov92/select-minutes-
92nov.txt).
[Almqu92] Almquist、P.、「選択評価基準転炉の数分」、ワシントンD.C.IETF、1992年11月(選んだ分ietf/nov92/92nov. txt)。
[Berkow94] Berkowitz, H., "IPng and Related Plug-and-Play Issues and
Requirements", Work in Progress, September 1994.
[Berkow94] バーコウィッツと、H.と、「IPng、関連Plug and Play問題、および要件」は進歩、1994年9月に働いています。
[Bos94] Bos, E. J., "Minutes of the Address Lifetime Expectations BOF
(ALE)", Seattle IETF, March 1994, (ietf/ale/ale-minutes-
94mar.txt).
[Bos94]ボス、E.J.、「アドレス生涯期待転炉(エール)の数分」、シアトルIETF、1994年3月(ietf/エール/エール数分-94mar. txt)。
[Big] Archives of the big-internet mailing list, on munnari.oz.au in
big-internet/list-archives.
リスト大きいインターネット/アーカイブのmunnari.oz.Auに関する大きいインターネットメーリングリストの[大きい]のアーカイブ。
[Bradner93] Bradner, S., and A. Mankin, "IP: Next Generation (IPng)
White Paper Solicitation", RFC 1550, Harvard University, NRL,
December 1993.
[Bradner93] ブラドナー、S.、およびA.マンキン、「IP:」 「次世代(IPng)白書懇願」、RFC1550、ハーバード大学、NRL、1993年12月。
[Callon87] Callon, R., "A Proposal for a Next Generation Internet
Protocol", Proposal to X3S3, December 1987.
[Callon87] Callon、R.、「次世代インターネットプロトコルのためのA提案」、X3S3への提案、1987年12月。
[Callon92a] Callon, R., "CNAT", Work in Progress.
[Callon92a]Callon R.、"CNAT"は進行中で働いています。
[Callon92b] Callon, R., "Simple CLNP", Work in Progress.
R.、「簡単なCLNP」という[Callon92b]Callonは進行中で働いています。
Bradner & Mankin [Page 48] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[48ページ]RFC1752推薦
[Callon92c] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A
Simple Proposal for Internet Addressing and Routing", RFC 1347,
DEC, June 1992.
[Callon92c]Callon、R.、「より大きいのがあるTCPとUDPは(tuba)、インターネットアドレシングとルート設定のための簡単な提案を記述します」、RFC1347、1992年12月、6月。
[Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
August 1993.
[Carpen93] 大工とB.とT.ディクソン、「IPng決定過程転炉(IPDECIDE)の数分」、/ietf/93jul/ipdecide数分93jul. txt、1993年8月。
[Carpen94b] Carpenter, B, and J. Bound, "Recommendations for OSI NSAP
usage in IPv6", Work in Progress.
[Carpen94b] 大工、BとJ.Bound、「OSI NSAP用法のためのIPv6"の推薦、ProgressのWork。」
[Chiappa91] Chiappa, J., "A New IP Routing and Addressing
Architecture", Work in Progress.
J.と、「新しいIPルート設定とアドレッシング体系」という[Chiappa91]Chiappaは進行中で働いています。
[Clark91] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby,
"Towards the Future Internet Architecture", RFC 1287, MIT, BBN,
CNRI, ISI, UC Davis, December 1991.
[Clark91] クラークとD.とチェーピンとL.とサーフとV.とブレーデン、R.とR.趣味、「今後のインターネット建築」、RFC1287、MIT、BBN、CNRI、ISI、UCデイヴィス(1991年12月)。
[Deering92] Deering, S., "The Simple Internet Protocol", Big-Internet
mailing list, 22 Sept. 1992.
[Deering92] デアリング、S.、「簡単なインターネットプロトコル」、Big-インターネットメーリングリスト、1992年9月22日。
[Deering94a] Deering, S., and P. Francis, Message to sipp mailing
list, 31 May 1994.
[Deering94a] sippメーリングリスト、1994年5月31日までのデアリング、S.とP.フランシス、Message。
[Estrin94b] Estrin, D., Zappala, D., Li, T., Rekhter, Y., and K.
Varadhan, "Source Demand Routing: Packet Format and Forwarding
Specification (Version 1)" Work in Progress.
[Estrin94b] Estrin、D.、Zappala、D.、李、T.、Rekhter、Y.、およびK.Varadhan、「以下を掘るソース要求」 「パケット・フォーマットと推進仕様(バージョン1)」は進行中で働いています。
[Fuller93] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC 1519, BARRNet, cisco Systems, MERIT, OARnet,
September 1993.
[Fuller93] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「Address AssignmentとAggregation Strategy」、RFC1519、BARRNet、コクチマスSystems MERIT、OARnet、9月1993日
[Gillig94c] Gilligan, B., "IPng Transition (ngtrans)", Work in
Progress.
[Gillig94c] ギリガン、B.、「IPng変遷(ngtrans)」が進行中で働いています。
[Gross92} Gross, P., and P. Almquist, "IESG Deliberations on Routing
and Addressing", RFC 1380, ANS, Stanford University, November
1992.
[Gross92、グロス、P.とP.Almquist、「ルート設定とアドレシングにおけるIESG熟考」RFC1380、ANSスタンフォード大学、11月1992日
[Gross94] Gross, P. "A Direction for IPng", RFC 1719, MCI, December
1994.
[Gross94]グロス、P. 「IPngのための指示」、RFC1719、MCI、1994年12月。
[Hinden92a] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS)", Work in Progress.
[Hinden92a] Hinden、R.、「インターネットルート設定の新しい計画、(ENCAPS)を記述すること」は進行中で働いています。
[Hinden94b] Hinden, R., Deering, S., and P. Francis, "Simple Internet
Protocol Plus", Working Group Charter, April 1994.
[Hinden94b] HindenとR.とデアリング、S.とP.フランシス、「簡単なインターネットプロトコルプラス」、ワーキンググループ憲章、1994年4月。
Bradner & Mankin [Page 49] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[49ページ]RFC1752推薦
[Hinden92b] Hinden, R., and D. Crocker, "A Proposal for IP Address
Encapsulation (IPAE): A Compatible version of IP with Large
Addresses", Work in Progress.
[Hinden92b] Hinden、R.、およびD.クロッカー、「IPのための提案はカプセル化(IPAE)を記述します」。 「Large AddressesとIPのCompatibleバージョン」、ProgressのWork。
[Huston94] Huston, G., and A. Bansal, draft charter for the
"Transition and Coexistence Including Testing (TACIT) Working
Group, June 1994.
[Huston94] ヒューストン、G.、およびA.Bansalは「(暗黙)の作業部会、1994年6月にテストするのを含む変遷と共存」のための特許を作成します。
[Huitema93] Huitema, C., "IAB Recommendations for an Intermediate
Strategy to Address the Issue of Scaling", RFC 1481, INRIA, July
1993.
[Huitema93]Huitema、C.、「中間的戦略がスケーリングの問題を記述するというIAB推薦」、RFC1481、INRIA、7月1993日
[Huitema94] Huitema, C., "The H ratio for address assignment
efficiency", RFC 1715, INRIA, October 1994.
[Huitema94] Huitema、C.、「アドレス課題効率のためのH比」、RFC1715、INRIA、1994年10月。
[IAB92] Internet Architecture Board, "IP Version 7", Work in
Progress.
[IAB92]インターネット・アーキテクチャ委員会、「何7インチも、仕事が中で進行するIPバージョン。」
[IAB94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
of IAB Workshop on Security in the Internet Architecture -
February 8-10, 1994", RFC 1636, USC/Informaiton Sciences
Institute, MIT Laboratory for Computer Science, Trusted
Information Systems, Inc., INRIA, IAB Chair, June 1994.
[IAB94]ブレーデン、R.、クラーク、D.、クロッカー、S.、およびC.Huitemaは「1994年2月8日〜10日の間、インターネット構造におけるセキュリティに関するIABワークショップについて報告します」、RFC1636、USC/Informaiton科学研究所、MITコンピュータサイエンス研究所、信じられた情報システム。Inc.、INRIA、IAB議長(1994年6月)。
[Kasten92] Kastenholz, F, and C. Partridge, "IPv7 Technical
Criteria", Work in Progress.
[Kasten92] Kastenholz、F、およびC.ヤマウズラ、「IPv7の技術的な評価基準」は進行中で働いています。
[Kasten94] Partridge, C., and F. Kastenholz, "Technical Criteria for
Choosing IP: The Next Generation (IPng)", RFC 1726, BBN Systems
and Technologies, FTP Software, December 1994.
[Kasten94] ヤマウズラ、C.、およびF.Kastenholz、「IPを選ぶ技術的な評価基準:」 「次の世代(IPng)」とRFC1726とBBNシステムと技術、FTPソフトウェア、1994年12月。
[Knopper94a] Knopper, M., and P. Ford, "TCP/UDP Over CLNP-Addressed
Networks (TUBA)", Working Group Charter, January 1994.
[Knopper94a] Knopper、M.、およびP.フォード、「CLNPによって記述される上のTCP/UDPは(tuba)をネットワークでつなぐ」ワーキンググループ憲章、1994年1月。
[Knopper94b] Knopper, M., and D. Piscitello, "Minutes of the BigTen
IPng Retreat, May 19 & 20 1994".
[Knopper94b] Knopper、M.とD.Piscitello、「BigTen IPng後退、5月19日と20日の1994年の数分。」
[Leiner93] Leiner, B., and Y. Rekhter, "The MultiProtocol Internet",
RFC 1560, USRA, IBM, December 1993.
[Leiner93]Leiner、B.とY.Rekhter、「MultiProtocolインターネット」RFC1560、USRA、IBM、1993年12月。
[Mankin94] Mankin, A., and S. Bradner, message to big-internet, tuba,
sipp, catnip and ietf mailing lists, 7 July 1994.
[Mankin94] マンキン、A.とS.ブラドナーと大きいインターネットへのメッセージとチューバとsippとキャットニップとietfメーリングリスト、1994年7月7日。
[Mills84] Mills, D. "Exterior Gateway Protocol Formal Specification",
RFC 904, UDEL, April 1984.
[Mills84]工場、D.「外のゲートウェイプロトコル形式仕様」、RFC904、UDEL、1984年4月。
[Mogul90] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
DECWRL, Stanford University, November 1990.
[Mogul90] ムガール人、J.とS.デアリング、「経路MTU発見」、RFC1191、DECWRL、スタンフォード大学、1990年11月。
Bradner & Mankin [Page 50] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[50ページ]RFC1752推薦
[Nat94] National Research Council, "Realizing the Information Future:
The Internet and Beyond", National Academy Press, 1994.
[Nat94]調査評議会、「情報未来がわかります:」 国家のアカデミーは、「インターネットと以遠」と1994に押します。
[Piscit94] Piscitello, D., "FTP Operation Over Big Address Records
(FOOBAR)", RFC 1639, Core Competence, June 1994.
[Piscit94] Piscitello、D.、「大きいアドレス記録(FOOBAR)の上のFTP操作」、RFC1639、コアコンピタンス、1994年6月。
[Provan91] Provan, D., "Transmitting IP Traffic over ARCNET
Networks", RFC 1051, Novell, February 1991.
[Provan91] Provan、D.、「ARCNETネットワークの上にIP交通を伝えます」、RFC1051、ノベル、1991年2月。
[Postel94] Postel, J., Editor, "Internet Official Protocol
Standards", RFC 1720, USC/Information Sciences Institute, November
1994.
[Postel94] ポステル、J.、エディタ、「インターネット公式プロトコル標準」、RFC1720、科学が1994年11月に設けるUSC/情報。
[Solens93a] Solensky, F., and T. Li, "Charter for the Address
Lifetime Expectations Working Group", FTP Software, Cisco Systems,
November 1993.
[Solens93a] Solensky、F.、およびT.李、「アドレス生涯期待ワーキンググループのための憲章」、FTPソフトウェア、シスコシステムズ、1993年11月。
[Solens93b] Solensky, F., "Minutes of the Address Lifetime
Expectations BOF (ALE)", Houston IETF, November 1993,
(ietf/ale/ale-minutes-93nov.txt).
[Solens93b] Solensky、F.、「アドレス生涯期待転炉(エール)の数分」、ヒューストンIETF、1993年11月(エールが93nov. txtをietf/エール/書き留めている)。
[Solens94] Solensky, F., "Minutes of the Address Lifetime
Expectations BOF (ALE)", Toronto IETF, July 1994, (ietf/ale/ale-
minutes-94jul.txt).
[Solens94] Solensky、F.、「アドレス生涯期待転炉(エール)の数分」、トロントIETF、1994年7月(ietf/エール/エール数分-94jul. txt)。
[Sukonnik94] Sukonnik, V., "Common Architecture for Next-Generation
IP (catnip), Working Group Charter, April 1994.
[Sukonnik94] Sukonnik、V.、「次世代IP(キャットニップ)、ワーキンググループ憲章、1994年4月のための一般的な構造。」
[Tsuchiya92] Tsuchiya, P., "The 'P' Internet Protocol", Work in
Progress.
P.、P'インターネットプロトコル」という[Tsuchiya92]Tsuchiyaは進行中で働いています。
[Ullmann93] Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
Process Software Corporation, June 1993.
[Ullmann93]ウルマン、R.、「TP/IX:」 「次のインターネット」、RFC1475は1993年6月にソフトウェア社を処理します。
Bradner & Mankin [Page 51] RFC 1752 Recommendation for IPng January 1995
IPng1995年1月のためのブラドナーとマンキン[51ページ]RFC1752推薦
Appendix G - Acknowledgments
付録G--承認
Reaching this stage of the recommendation would not have been even vaguely possible without the efforts of many people. In particular, the work of IPng Directorate (listed in Appendix B), Frank Kastenholz and Craig Partridge (the authors of the Criteria document) along with Jon Crowcroft (who co-chaired the ngreq BOF) was critical. The work and cooperation of the chairs, members and document authors of the three IPng proposal working groups, the ALE working group and the TACIT working group laid the groundwork upon which this recommendation sits.
推薦のこのステージに達するのは多くの人々の努力なしでばく然と可能になりさえしなかったでしょう。 特にジョン・クロウクロフトに伴うIPng Directorate(Appendix Bでは、記載されている)、フランクKastenholz、およびクレイグPartridge(Criteriaドキュメントの作者)の仕事、(だれが共同議長を務めたか、ngreq BOF)、批判的です。 3つのIPng提案ワーキンググループ、ALEワーキンググループ、およびTACITワーキンググループのいす、メンバー、およびドキュメント作者の仕事と協力はこの推薦が座る土台を置きました。
We would also like to thank the many people who took the time to respond to RFC1550 and who provided the broad understanding of the many requirements of data networking that any proposal for an IPng must address.
また、わざわざRFC1550に応じて、IPngのためのどんな提案も記述しなければならないデータネットワークの多くの要件の広い理解を提供した多くの人々に感謝申し上げます。
The members of the IESG, the IAB, and the always active participants in the various mailing lists provided us with many insights into the issues we faced.
様々なメーリングリストのIESG、IAB、およびいつも活発な関係者のメンバーは私たちが直面していた問題への多くの洞察を私たちに提供しました。
Many other individuals gave us sometimes spirited but always useful counsel during this process. They include (in no particular order) Radia Perlman, Noel Chiappa, Peter Ford, Dave Crocker, Tony Li, Dave Piscitello, Vint Cerf and Dan Lynch.
多くの他の個人がこの過程の間、時々活発な、しかし、いつも役に立つカウンセリングを私たちに与えました。 彼らはRadiaパールマン、クリスマスChiappa、ピーター・フォード、デーヴ・クロッカー、トニー・李、デーヴPiscitello、Vintサーフ、およびダン・リンチを含んでいます(特に決まった順番でなく)。
Thanks to David Williams and Cheryl Chapman who took on the occasionally impossible task of ensuring that what is written here resembles English to some degree.
ここに書かれているものが英語にある程度類似しているのを確実にする時折不可能なタスクを引き受けたデヴィッド・ウィリアムスとシェリル・チャップマンをありがとうございます。
To all of the many people mentioned above and those we have skipped in our forgetfulness, thank you for making this task doable.
私たちがこのタスクをできるようにしながら私たちの忘れっぽさでスキップして、感謝する前記のように多くの人々とそれらのすべてに。
Bradner & Mankin [Page 52]
ブラドナーとマンキン[52ページ]
一覧
スポンサーリンク
