RFC3791 日本語訳
3791 Survey of IPv4 Addresses in Currently Deployed IETF Routing AreaStandards Track and Experimental Documents. C. Olvera, P. Nesser, II. June 2004. (Format: TXT=27567 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Olvera
Request for Comments: 3791 Consulintel
Category: Informational P. Nesser, II
Nesser & Nesser Consulting
June 2004
コメントを求めるワーキンググループC.オルベラ要求をネットワークでつないでください: 3791年のConsulintelカテゴリ: 情報のP.Nesser、II Nesser、および2004年6月に相談するNesser
Survey of IPv4 Addresses in Currently Deployed
IETF Routing Area Standards Track and Experimental Documents
IPv4の調査は、現在配布しているIETFでルート設定が領域標準化過程と実験ドキュメントであると扱います。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
仕事が現在のIPv4アドレスのすべての用法がIETFルート設定Areaを配布したドキュメントに求めるこの調査は規格を記録しました。 首尾よくすべてのIPv4インターネットからすべてのIPv6インターネットに移行するために、多くの中間の段階を取るでしょう。 これらのステップの1つはIPv4の依存を持っている現在のプロトコルの発展です。 これらのプロトコル(そして、それらの実装)がネットワーク・アドレス独立者であることが再設計されることが望まれていますが、それに失敗するのは二元的にIPv4とIPv6を少なくともサポートするでしょう。 このために、Experimental RFCsと同様にすべてのStandards(完全、Draft、およびProposed)が調査されるでしょう、そして、どんな依存も記録されるでしょう。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards. . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards . . . . . . . . . . . . . . . . . . . . . . . 3
5. Proposed Standards. . . . . . . . . . . . . . . . . . . . . . 3
6. Experimental RFCs . . . . . . . . . . . . . . . . . . . . . . 7
7. Summary of Results. . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 12
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 組織. . . . . . . . . . . . . . . . . . . . 2 3を記録してください。 完全な規格。 . . . . . . . . . . . . . . . . . . . . . . . 3 4. 規格. . . . . . . . . . . . . . . . . . . . . . . 3 5を作成してください。 提案された標準。 . . . . . . . . . . . . . . . . . . . . . 3 6. 実験的なRFCs. . . . . . . . . . . . . . . . . . . . . . 7 7。 結果の概要。 . . . . . . . . . . . . . . . . . . . . . 9 8. セキュリティ問題. . . . . . . . . . . . . . . . . . . 12 9。 承認。 . . . . . . . . . . . . . . . . . . . . . . 12 10. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. 引用規格. . . . . . . . . . . . . . . . . . 13 10.2。 有益な参照. . . . . . . . . . . . . . . . . 13
Olvera & Nesser II Informational [Page 1] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[1ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 14 12. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15
11. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 14 12. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 15
1. Introduction
1. 序論
This work aims to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. Also, throughout this document there are discussions on how routing protocols might be updated to support IPv6 addresses.
IETFルート設定Areaであると配布された現在のIPv4アドレスのすべての用法を記録するこの仕事目的は規格を記録しました。 また、このドキュメント中に、IPv6にアドレスをサポートするためにどうルーティング・プロトコルをアップデートするかもしれないかについての議論があります。
This material was originally presented within a single document, but in an effort to have the information in a manageable form, it has subsequently been split into 7 documents conforming to the current IETF main areas (Application [2], Internet [3], Operations & Management [4], Routing [this document], Security [5], Sub-IP [6] and Transport [7]).
この材料は元々、ただ一つのドキュメントの中に示されましたが、処理しやすいフォームに情報を持つ取り組みでは、それは次に、現在のIETF主な領域に従うのが7通のドキュメントに分けられました。(Sub-IPのアプリケーション[2]、インターネット[3]、Operations&Management[4]、ルート設定[このドキュメント]、Security[5]、[6]、およびTransport[7])。
The general overview, methodology used during documentation and scope of the investigation for the whole 7 documents can be found in the introduction of this set of documents [1].
概要、このセットのドキュメント[1]の導入で全体の7通のドキュメントに調査のドキュメンテーションと範囲の間に使用される方法論は見つけることができます。
It is important to mention that to perform this study the following classes of IETF standards are investigated: Full, Draft, and Proposed, as well as Experimental. Informational, BCP and Historic RFCs are not addressed. RFCs that have been obsoleted by either newer versions or as they have transitioned through the standards process are also not covered.
この研究を実行するために、以下のクラスのIETF規格が調査されると言及するのは重要です: 完全、Draft、Proposed、およびExperimental。 情報であり、BCPとHistoric RFCsは扱われません。 また、より新しいバージョンによって時代遅れにされるか、または標準化過程で移行したとき、それがRFCsであったのはカバーされていません。
2. Document Organization
2. ドキュメント組織
The main Sections of this document are described below.
このドキュメントの主なセクションは以下で説明されます。
Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, Proposed Standards and Experimental RFCs. Each RFC is discussed in its turn starting with RFC 1 and ending (around) RFC 3100. The comments for each RFC are "raw" in nature. That is, each RFC is discussed in a vacuum and problems or issues discussed do not "look ahead" to see if the problems have already been fixed.
それぞれセクション3、4、5、および6はFull、Draft、Proposed Standards、およびExperimental RFCsの生の分析について説明します。 RFC1と(around) RFC3100を終わらせることをきっかけに自分の番になって、各RFCについて議論します。 各RFCのためのコメントは現実に「生です」。 真空ですなわち各RFCについて議論します、そして、問題か議論した問題が、既に問題を修正してあるかどうか確認するために「前を見ません」。
Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 6. It is here that all of the results are considered as a whole and the problems that have been resolved in later RFCs are correlated.
セクション7はセクション3、4、5、および6に提示されたデータの分析です。 結果のすべてが全体で考えられて、後のRFCsで解決された問題が関連されているのが、ここにそれがあります。
Olvera & Nesser II Informational [Page 2] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[2ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
3. Full Standards
3. 完全な規格
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
完全なインターネットStandards(最も一般的に単に「規格」と呼ばれる)は広く履行されて、インターネット中で使用される完全に熟しているプロトコル仕様です。
3.1. RFC 1722 (STD 57) RIP Version 2 Protocol Applicability Statement
3.1. RFC1722(STD57)はバージョン2プロトコル適用性証明を裂きます。
RIPv2 is only intended for IPv4 networks.
RIPv2はIPv4ネットワークのために意図するだけです。
3.2. RFC 2328 (STD 54) OSPF Version 2
3.2. RFC2328(STD54)OSPFバージョン2
This RFC defines a protocol for IPv4 routing. It is highly assumptive about address formats being IPv4 in nature.
このRFCはIPv4ルーティングのためにプロトコルを定義します。 それは非常に現実にIPv4であるアドレス形式に関して仮定です。
3.3. RFC 2453 (STD 56) RIP Version 2
3.3. RFC2453(STD56)はバージョン2をコピーします。
RIPv2 is only intended for IPv4 networks.
RIPv2はIPv4ネットワークのために意図するだけです。
4. Draft Standards
4. 草稿規格
Draft Standards represent the penultimate standard level in the IETF. A protocol can only achieve draft standard when there are multiple, independent, interoperable implementations. Draft Standards are usually quite mature and widely used.
草稿StandardsはIETFに終わりから二番目の標準のレベルを表します。 複数の、そして、独立していて、共同利用できる実装があるときだけ、プロトコルは草稿規格を実現できます。 草稿Standardsは通常、かなり熟して広く使用されています。
4.1. RFC 1771 A Border Gateway Protocol 4 (BGP-4)
4.1. ボーダ・ゲイトウェイ・プロトコル4あたりRFC1771(BGP-4)
This RFC defines a protocol used for exchange of IPv4 routing information and does not support IPv6 as is defined.
このRFCはIPv4ルーティング情報の交換に使用されるプロトコルを定義して、そのままで定義されていた状態でIPv6をサポートしません。
4.2. RFC 1772 Application of the Border Gateway Protocol in the Internet
4.2. インターネットでのボーダ・ゲイトウェイ・プロトコルのRFC1772応用
This RFC is a discussion of the use of BGP-4 on the Internet.
このRFCはインターネットにおけるBGP-4の使用の議論です。
4.3. RFC 3392 Capabilities Advertisement with BGP-4
4.3. BGP-4とのRFC3392能力広告
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only.
プロトコル増進には、IPv4の依存が全くありませんが、ベースプロトコル(BGP-4)はIPv4専用です。
5. Proposed Standards
5. 提案された標準
Proposed Standards are introductory level documents. There are no requirements for even a single implementation. In many cases Proposed are never implemented or advanced in the IETF standards process. They therefore are often just proposed ideas that are presented to the Internet community. Sometimes flaws are exposed or
提案されたStandardsは紹介している平らなドキュメントです。 ただ一つの実装さえのための要件が全くありません。 多くの場合、ProposedはIETF標準化過程で実装されるか、または決して進められません。 したがって、それらはインターネットコミュニティに提示されるしばしばただ提案された考えです。 または時々、欠点が暴露される。
Olvera & Nesser II Informational [Page 3] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[3ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
they are one of many competing solutions to problems. In these later cases, no discussion is presented as it would not serve the purpose of this discussion.
彼らは問題への多くの競争している解決の1つです。これらの後の場合では、この議論の目的に役立たないように議論は全く提示されません。
5.1. RFC 1195 Use of OSI IS-IS for routing in TCP/IP and dual
environments
5.1. RFC1195Use、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在
This document specifies a protocol for the exchange of IPv4 routing information.
このドキュメントはIPv4ルーティング情報の交換にプロトコルを指定します。
5.2. RFC 1370 Applicability Statement for OSPF
5.2. OSPFのためのRFC1370適用性証明
This document discusses a version of OSPF that is limited to IPv4.
このドキュメントはIPv4に制限されるOSPFのバージョンについて議論します。
5.3. RFC 1397 Default Route Advertisement In BGP2 and BGP3 Version of
The Border Gateway Protocol
5.3. ボーダ・ゲイトウェイ・プロトコルのBGP2とBGP3バージョンにおけるRFC1397デフォルトルート広告
BGP2 and BGP3 are both deprecated and therefore are not discussed in this document.
BGP2とBGP3についてともに推奨しなく、したがって、本書では議論しません。
5.4. RFC 1478 An Architecture for Inter-Domain Policy Routing
5.4. 相互ドメイン方針ルート設定のための1アーキテクチャあたりRFC1478
The architecture described in this document has no IPv4 dependencies.
本書では説明されたアーキテクチャはIPv4の依存を全く持っていません。
5.5. RFC 1479 Inter-Domain Policy Routing Protocol Specification:
Version 1 (IDPR)
5.5. RFC1479相互ドメイン方針ルート設定プロトコル仕様: バージョン1(IDPR)
There are no IPv4 dependencies in this protocol.
このプロトコルにおけるIPv4の依存が全くありません。
5.6. RFC 1517 Applicability Statement for the Implementation of
Classless Inter-Domain Routing (CIDR)
5.6. 階級のない相互ドメインルート設定の実装のためのRFC1517適用性証明(CIDR)
This document deals exclusively with IPv4 addressing issue.
このドキュメントは排他的に問題を扱うIPv4に対処します。
5.7. RFC 1518 An Architecture for IP Address Allocation with CIDR
5.7. CIDRとのIPアドレス配分のための1アーキテクチャあたりRFC1518
This document deals exclusively with IPv4 addressing issue.
このドキュメントは排他的に問題を扱うIPv4に対処します。
5.8. RFC 1519 Classless Inter-Domain Routing (CIDR): an Address
Assignment and Aggregation Strategy
5.8. RFC1519の階級のない相互ドメインルート設定(CIDR): アドレス課題と集合戦略
This document deals exclusively with IPv4 addressing issue.
このドキュメントは排他的に問題を扱うIPv4に対処します。
5.9. RFC 1582 Extensions to RIP to Support Demand Circuits
5.9. 要求が回路であるとサポートするために裂くRFC1582拡張子
This protocol is an extension to a protocol for exchanging IPv4 routing information.
このプロトコルはIPv4ルーティング情報を交換するためのプロトコルへの拡大です。
Olvera & Nesser II Informational [Page 4] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[4ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
5.10. RFC 1584 Multicast Extensions to OSPF
5.10. OSPFへのRFC1584マルチキャスト拡張子
This document defines the use of IPv4 multicast to an IPv4 only routing protocol.
このドキュメントはプロトコルを発送するだけであるIPv4とIPv4マルチキャストの使用を定義します。
5.11. RFC 1793 Extending OSPF to Support Demand Circuits
5.11. 要求が回路であるとサポートするためにOSPFを広げるRFC1793
There are no IPv4 dependencies in this protocol other than the fact that it is a new functionality for a routing protocol that only supports IPv4 networks.
それがIPv4にネットワークをサポートするだけであるルーティング・プロトコルのための新しい機能性であるという事実以外のこのプロトコルにおけるIPv4の依存が全くありません。
5.12. RFC 1997 BGP Communities Attribute
5.12. RFC1997BGP共同体属性
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only.
プロトコル増進には、IPv4の依存が全くありませんが、ベースプロトコル(BGP-4)はIPv4専用です。
5.13. RFC 2080 RIPng for IPv6
5.13. IPv6のためのRFC2080RIPng
This RFC documents a protocol for exchanging IPv6 routing information and is not discussed in this document.
このRFCについてIPv6ルーティング情報を交換するためにプロトコルを記録して、本書では議論しません。
5.14. RFC 2091 Triggered Extensions to RIP to Support Demand Circuits
5.14. RFC2091は要求が回路であるとサポートするために裂く拡大の引き金となりました。
This RFC defines an enhancement for an IPv4 routing protocol and while it has no IPv4 dependencies it is inherently limited to IPv4.
このRFCはIPv4ルーティング・プロトコルのための増進を定義します、そして、IPv4の依存が全くない間、それは本来IPv4に制限されます。
5.15. RFC 2338 Virtual Router Redundancy Protocol (VRRP)
5.15. RFC2338の仮想のルータ冗長プロトコル(VRRP)
This protocol is IPv4 specific, there are numerous references to 32- bit IP addresses.
このプロトコルがIPv4特有である、IPが扱う32ビットの頻繁な参照があります。
5.16. RFC 2370 The OSPF Opaque LSA Option
5.16. RFC2370のOSPFの不明瞭なLSAオプション
There are no IPv4 dependencies in this protocol other than the fact that it is a new functionality for a routing protocol that only supports IPv4 networks.
それがIPv4にネットワークをサポートするだけであるルーティング・プロトコルのための新しい機能性であるという事実以外のこのプロトコルにおけるIPv4の依存が全くありません。
5.17. RFC 2439 BGP Route Flap Damping
5.17. RFC2439BGPルートフラップ湿気
The protocol enhancements have no IPv4 dependencies, even though the base protocol, BGP-4, is IPv4 only routing protocol.
プロトコル増進には、ベースプロトコル(BGP-4)はプロトコルを発送するだけであるIPv4ですが、IPv4の依存が全くありません。
5.18. RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-
Domain Routing
5.18. BGP-4 Multiprotocol拡張子のIPv6相互ドメインルート設定のRFC2545使用
This RFC documents IPv6 routing methods and is not discussed in this document.
このRFCについてIPv6ルーティング方式を記録して、本書では議論しません。
Olvera & Nesser II Informational [Page 5] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[5ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
5.19. RFC 2740 OSPF for IPv6
5.19. IPv6のためのRFC2740OSPF
This document defines an IPv6 specific protocol and is not discussed in this document.
このドキュメントについて、IPv6の特定のプロトコルを定義して、本書では議論しません。
5.20. RFC 2784 Generic Routing Encapsulation (GRE)
5.20. RFC2784一般ルーティングのカプセル化(GRE)
This protocol is only defined for IPv4. The document states in the Appendix:
このプロトコルはIPv4のために定義されるだけです。 ドキュメントはAppendixに以下を述べます。
o IPv6 as Delivery and/or Payload Protocol
o 配送、そして/または、有効搭載量プロトコルとしてのIPv6
This specification describes the intersection of GRE currently deployed by multiple vendors. IPv6 as delivery and/or payload protocol is not included.
この仕様は現在複数のベンダーによって配布されているGREの交差点について説明します。 配送、そして/または、ペイロードプロトコルとしてのIPv6は含まれていません。
5.21. RFC 2796 BGP Route Reflection - An Alternative to Full Mesh IBGP
5.21. RFC2796BGPルート反射--完全なメッシュIBGPへの代替手段
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only routing protocol. This specification updates but does not obsolete RFC 1966.
プロトコル増進には、IPv4の依存が全くありませんが、ベースプロトコル(BGP-4)はプロトコルを発送するだけであるIPv4です。 この仕様は、どんな時代遅れのRFC1966もアップデートしますが、しません。
5.22. RFC 2858 Multiprotocol Extensions for BGP-4
5.22. BGP-4のためのRFC2858Multiprotocol拡張子
In the Abstract:
要約で:
Currently BGP-4 is capable of carrying routing information only for IPv4. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
現在の、BGP-4はIPv4のためだけのルーティング情報を運ぶことができます。 このドキュメントは、複数のNetwork Layerプロトコル(例えば、IPv6、IPXなど)のためのルーティング情報を運ぶのを可能にするために拡大をBGP-4と定義します。 拡大が後方である、コンパチブル、--拡大をサポートするルータは拡大をサポートしないルータで共同利用できます。
The document is therefore not examined further in this document.
したがって、ドキュメントはさらに本書では調べられません。
5.23. RFC 2890 Key and Sequence Number Extensions to GRE
5.23. GREへの2890年のRFCキーと一連番号拡大
There are no IPv4 dependencies in this protocol.
このプロトコルにおけるIPv4の依存が全くありません。
5.24. RFC 2894 Router Renumbering for IPv6
5.24. IPv6のためのRFC2894ルータの番号を付け替えること
The RFC defines an IPv6 only document and is not concerned in this survey.
RFCが定義する、IPv6はこの調査で記録して、当該であるだけではありません。
5.25. RFC 2918 Route Refresh Capability for BGP-4
5.25. RFC2918ルートはBGP-4のために能力をリフレッシュします。
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only routing protocol.
プロトコル増進には、IPv4の依存が全くありませんが、ベースプロトコル(BGP-4)はプロトコルを発送するだけであるIPv4です。
Olvera & Nesser II Informational [Page 6] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[6ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
5.26. RFC 3065 Autonomous System Confederations for BGP
5.26. BGPのためのRFC3065自律システム同盟者
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only routing protocol.
プロトコル増進には、IPv4の依存が全くありませんが、ベースプロトコル(BGP-4)はプロトコルを発送するだけであるIPv4です。
5.27. RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option
5.27. RFC3101OSPFしたがって、短く太くない領域(NSSA)オプション
This document defines an extension to an IPv4 routing protocol.
このドキュメントはIPv4ルーティング・プロトコルと拡大を定義します。
5.28. RFC 3107 Carrying Label Information in BGP-4
5.28. BGP-4のラベル情報を運ぶRFC3107
There are no IPv4 dependencies in this protocol.
このプロトコルにおけるIPv4の依存が全くありません。
5.29. RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse
Discovery Specification
5.29. 逆さの発見仕様のためのIPv6隣人発見へのRFC3122拡張子
This is an IPv6 related document and is not discussed in this document.
これについて、IPv6の関連するドキュメントであり、本書では議論しません。
6. Experimental RFCs
6. 実験的なRFCs
Experimental RFCs typically define protocols that do not have wide scale implementation or usage on the Internet. They are often propriety in nature or used in limited arenas. They are documented to the Internet community in order to allow potential interoperability or some other potential useful scenario. In a few cases they are presented as alternatives to the mainstream solution to an acknowledged problem.
実験的なRFCsはインターネットに広いスケール実装か用法を持っていないプロトコルを通常定義します。 しばしばそれらは限られたアリーナで自然か中古の正当です。 それらは、潜在的相互運用性かある他の潜在的役に立つシナリオを許容するためにインターネットコミュニティに記録されます。 いくつかの場合では、それらは主流のソリューションへの代替手段として承認された問題に提示されます。
6.1. RFC 1075 Distance Vector Multicast Routing Protocol (DVMRP)
6.1. RFC1075ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル(DVMRP)
This document defines a protocol for IPv4 multicast routing.
このドキュメントはIPv4マルチキャストルーティングのためにプロトコルを定義します。
6.2. RFC 1383 An Experiment in DNS Based IP Routing
6.2. DNSの1実験あたりRFC1383はIPルート設定を基礎づけました。
This proposal is IPv4 limited:
この提案は制限されたIPv4です:
This record is designed for easy general purpose extensions in the DNS, and its content is a text string. The RX record will contain three fields: A record identifier, A cost indicator, and An IP address.
この記録はDNSでの簡単な汎用の拡大のために設計されています、そして、内容はテキスト文字列です。 RX記録は3つの分野を含むでしょう: レコード識別名、Aはインディケータ、およびAn IPアドレスかかります。
Olvera & Nesser II Informational [Page 7] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[7ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
The three strings will be separated by a single comma. An example of record would thus be:
3個のストリングがただ一つのコンマによって分離されるでしょう。 その結果、記録に関する例は以下の通りでしょう。
___________________________________________________________________ | domain | type | record | value | | - | | | | |*.27.32.192.in-addr.arpa | IP | TXT | RX, 10, 10.0.0.7| |_________________________|________|__________|___________________|
___________________________________________________________________ | ドメイン| タイプ| 記録| 値| | - | | | | |*.27.32.192.in-addr.arpa| IP| TXT| RX、10、10.0、.0、.7| |_________________________|________|__________|___________________|
which means that for all hosts whose IP address starts by the three octets "192.32.27" the IP host "10.0.0.7" can be used as a gateway, and that the preference value is 10.
どれがIPアドレスが3つの八重奏で始まるすべてのホストのためにそれを意味するか、「192.320.27インチIPが接待する、「10.0 .0 ゲートウェイとして0.7インチを使用できます、そして、好みの値は10です」
6.3. RFC 1476 RAP: Internet Route Access Protocol
6.3. RFC1476は叩きます: インターネットルートアクセス・プロトコル
This document defines an IPv7 routing protocol and has been abandoned by the IETF as a feasible design. It is not considered in this document.
このドキュメントは、IPv7ルーティング・プロトコルを定義して、可能なデザインとしてIETFによって捨てられました。 それは本書では考えられません。
6.4. RFC 1765 OSPF Database Overflow
6.4. RFC1765OSPFデータベースオーバーフロー
There are no IPv4 dependencies in this protocol other than the fact that it is a new functionality for a routing protocol that only supports IPv4 networks.
それがIPv4にネットワークをサポートするだけであるルーティング・プロトコルのための新しい機能性であるという事実以外のこのプロトコルにおけるIPv4の依存が全くありません。
6.5. RFC 1863 A BGP/IDRP Route Server alternative to a full mesh
routing
6.5. 完全なメッシュルーティングへのRFC1863A BGP/IDRP Route Server代替手段
This protocol is both IPv4 and IPv6 aware and needs no changes.
このプロトコルは、IPv4とIPv6ともに意識していて、変化を全く必要としません。
6.6. RFC 1966 BGP Route Reflection An alternative to full mesh IBGP
6.6. 完全なメッシュIBGPへのRFC1966BGP Route Reflection An代替手段
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only routing protocol. This specification has been updated by RFC 2796.
プロトコル増進には、IPv4の依存が全くありませんが、ベースプロトコル(BGP-4)はプロトコルを発送するだけであるIPv4です。 この仕様はRFC2796によってアップデートされました。
6.7. RFC 2189 Core Based Trees (CBT version 2) Multicast Routing
6.7. RFC2189Core Based Trees(CBTバージョン2)マルチキャストルート設定
The document specifies a protocol that depends on IPv4 multicast. There are many packet formats defined that show IPv4 usage.
ドキュメントはIPv4マルチキャストによるプロトコルを指定します。 用法をIPv4に示している定義された多くのパケット・フォーマットがあります。
6.8. RFC 2201 Core Based Trees (CBT) Multicast Routing Architecture
6.8. RFC2201コアは木(CBT)のマルチキャストルート設定アーキテクチャを基礎づけました。
See previous Section for the IPv4 limitation in this protocol.
このプロトコルにおけるIPv4制限に関して前のセクションを見てください。
Olvera & Nesser II Informational [Page 8] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[8ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
6.9. RFC 2337 Intra-LIS IP multicast among routers over ATM using
Sparse Mode PIM
6.9. Sparse Mode PIMを使用するATMの上のルータの中のRFC2337Intra-LIS IPマルチキャスト
This protocol is designed for IPv4 multicast.
このプロトコルはIPv4マルチキャストのために設計されています。
6.10. RFC 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification
6.10. RFC2362は独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べます: プロトコル仕様
This protocol is both IPv4 and IPv6 aware and needs no changes.
このプロトコルは、IPv4とIPv6ともに意識していて、変化を全く必要としません。
6.11. RFC 2676 QoS Routing Mechanisms and OSPF Extensions
6.11. RFC2676QoSルート設定メカニズムとOSPF拡張子
There are IPv4 dependencies in this protocol. It requires the use of the IPv4 TOS header field.
このプロトコルにおけるIPv4の依存があります。 それはIPv4 TOSヘッダーフィールドの使用を必要とします。
7. Summary of Results
7. 結果の概要
In the initial survey of RFCs, 23 positives were identified out of a total of 46, broken down as follows:
RFCsの初期の調査では、23の正数が合計以下の通り破壊された46から特定されました:
Standards: 3 out of 3 or 100.00%
Draft Standards: 1 out of 3 or 33.33%
Proposed Standards: 13 out of 29 or 44.83%
Experimental RFCs: 6 out of 11 or 54.54%
規格: 3%か100.00%のうちの3は規格を作成します: 3%か33.33%のうちの1は規格を提案しました: 29のうちの13か44.83%の実験的なRFCs: 6 11%か54.54%から
Of those identified many require no action because they document outdated and unused protocols, while others are document protocols that are actively being updated by the appropriate working groups. Additionally there are many instances of standards that should be updated but do not cause any operational impact if they are not updated. The remaining instances are documented below. The authors have attempted to organize the results in a format that allows easy reference to other protocol designers. The assignment of statements has been based entirely on the authors perceived needs for updates and should not be taken as an official statement.
多く特定されたものでは、彼らが時代遅れの、そして、未使用のプロトコルを記録するので、動作を全く必要としないでください、他のものは適切なワーキンググループによって活発にアップデートされているドキュメントプロトコルですが。 さらに、それらをアップデートしないなら、アップデートするべきですが、どんな操作上の影響も引き起こさない規格の多くのインスタンスがあります。 残っているインスタンスは以下に記録されます。 作者は、他のプロトコルデザイナーについての簡単な言及を許す形式で結果を組織化するのを試みました。 声明の課題をアップデートの必要性であると知覚された作者に完全に基礎づけて、公式声明としてみなすべきではありません。
7.1. Standards
7.1. 規格
7.1.1. STD 57 RIP Version 2 Protocol Applicability Statement (RFC 1722)
7.1.1. STD57はバージョン2プロトコル適用性証明を裂きます。(RFC1722)
This problem has been fixed by RFC 2081, RIPng Protocol Applicability Statement.
RIPngプロトコルApplicability Statement、この問題はRFC2081によって修正されました。
Olvera & Nesser II Informational [Page 9] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[9ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
7.1.2. STD 54 OSPF Version 2 (RFC 2328)
7.1.2. STD54OSPFバージョン2(RFC2328)
This problem has been fixed by RFC 2740, OSPF for IPv6.
この問題はRFC2740、IPv6のためのOSPFによって修正されました。
7.1.3. STD 56 RIP Version 2 (RFC 2453)
7.1.3. STD56はバージョン2をコピーします。(RFC2453)
This problem has been fixed by RFC 2080, RIPng for IPv6.
この問題はRFC2080、IPv6のためのRIPngによって修正されました。
7.2. Draft Standards
7.2. 草稿規格
7.2.1. Border Gateway Protocol 4 (RFC 1771)
7.2.1. ボーダ・ゲイトウェイ・プロトコル4(RFC1771)
This problem has been fixed in RFC 2858 Multiprotocol Extensions for BGP-4, RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, and in [8].
BGP-4のためのRFC2858Multiprotocol Extensions、IPv6 Inter-ドメインルート設定のためのBGP-4 Multiprotocol ExtensionsのRFC2545Useと[8]でこの問題を修正してあります。
RFC 2858 extends BGP to support multi-protocol extensions that allows routing information for other address families to be exchanged. RFC 2545 further extends RFC 2858 for full support of exchanging IPv6 routing information and additionally clarifies support of the extended BGP-4 protocol using TCP+IPv6 as a transport mechanism. RFC 1771, 2858 & 2545 must be supported in order to provide full IPv6 support.
RFC2858は、他のアドレスファミリーを交換するためにそれが許すマルチプロトコル拡大にルーティング情報をサポートするためにBGPを広げています。 RFC2545より遠くに、拡張BGP-4プロトコルのサポートは、移送機構としてTCP+IPv6を使用することで情報を発送しながらIPv6を交換する全面的な支援のためにRFC2858を広げていて、さらに、はっきりさせられます。 完全なIPv6サポートを提供するためにRFC1771、2858と2545をサポートしなければなりません。
Note also that all the BGP extensions analyzed previously in this memo function without changes with the updated version of BGP-4.
また、以前にこのメモで分析されたすべてのBGP拡張子がBGP-4のアップデートされたバージョンで変化なしで機能することに注意してください。
7.3. Proposed Standards
7.3. 提案された標準
7.3.1. Use of OSI IS-IS for routing in TCP/IP and dual environments
(RFC 1195)
7.3.1. 使用、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在(RFC1195)
This problem is being addressed by the IS-IS WG [9].
この問題が扱われている、-、IS WG、[9]。
7.3.2. Applicability Statement for OSPFv2 (RFC 1370)
7.3.2. OSPFv2のための適用性証明(RFC1370)
This problem has been resolved in RFC 2740, OSPF for IPv6.
この問題はRFC2740、IPv6のためのOSPFで解決されました。
7.3.3. Applicability of CIDR (RFC 1517)
7.3.3. CIDRの適用性(RFC1517)
The contents of this specification has been treated in various IPv6 addressing architecture RFCs, see RFC 3513 & 3587.
RFC3513と3587は、アーキテクチャがRFCsであると扱いながらこの仕様の内容が様々なIPv6で扱われたのを見ます。
7.3.4. CIDR Architecture (RFC 1518)
7.3.4. CIDRアーキテクチャ(RFC1518)
The contents of this specification has been treated in various IPv6 addressing architecture RFCs, see RFC 3513 & 3587.
RFC3513と3587は、アーキテクチャがRFCsであると扱いながらこの仕様の内容が様々なIPv6で扱われたのを見ます。
Olvera & Nesser II Informational [Page 10] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[10ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
7.3.5. Classless Inter-Domain Routing (CIDR): an Address Assignment
and Aggregation Strategy (RFC 1519)
7.3.5. 階級のない相互ドメインルート設定(CIDR): アドレス課題と集合戦略(RFC1519)
The contents of this specification has been treated in various IPv6 addressing architecture RFCs, see RFC 3513 & 3587.
RFC3513と3587は、アーキテクチャがRFCsであると扱いながらこの仕様の内容が様々なIPv6で扱われたのを見ます。
7.3.6. RIP Extensions for Demand Circuits (RFC 1582)
7.3.6. 要求回路のための拡大を裂いてください。(RFC1582)
This problem has been addressed in RFC 2080, RIPng for IPv6.
この問題はRFC2080、IPv6のためのRIPngで扱われました。
7.3.7. OSPF Multicast Extensions (RFC 1584)
7.3.7. OSPFマルチキャスト拡張子(RFC1584)
This functionality has been covered in RFC 2740, OSPF for IPv6.
RFC2740、IPv6のためのOSPFでこの機能性をカバーしています。
7.3.8. OSPF For Demand Circuits (RFC 1793)
7.3.8. 要求回路へのOSPF(RFC1793)
This functionality has been covered in RFC 2740, OSPF for IPv6.
RFC2740、IPv6のためのOSPFでこの機能性をカバーしています。
7.3.9. RIP Triggered Extensions for Demand Circuits (RFC 2091)
7.3.9. 要求回路のための引き起こされた拡大を裂いてください。(RFC2091)
This functionality is provided in RFC 2080, RIPng for IPv6.
RFC2080、IPv6のためのRIPngにこの機能性を提供します。
7.3.10. Virtual Router Redundancy Protocol (VRRP)(RFC 2338)
7.3.10. 仮想のルータ冗長プロトコル(VRRP)(RFC2338)
The problems identified are being addressed by the VRRP WG [10].
特定された問題はVRRP WG[10]によって扱われています。
7.3.11. OSPF Opaque LSA Option (RFC 2370)
7.3.11. OSPFの不明瞭なLSAオプション(RFC2370)
This problem has been fixed by RFC 2740, OSPF for IPv6. Opaque options support is an inbuilt functionality in OSPFv3.
この問題はRFC2740、IPv6のためのOSPFによって修正されました。 不透明なオプションサポートはOSPFv3のinbuiltの機能性です。
7.3.12. Generic Routing Encapsulation (GRE)(RFC 2784)
7.3.12. 一般ルーティングのカプセル化(GRE)(RFC2784)
Even though GRE tunneling over IPv6 has been implemented and used, its use has not been formally specified. Clarifications are required.
IPv6の上でトンネルを堀るGREが実装されて、使用されましたが、使用は正式に指定されていません。 明確化が必要です。
7.3.13. OSPF NSSA Option (RFC 3101)
7.3.13. OSPF NSSAオプション(RFC3101)
This functionality has been covered in RFC 2740, OSPF for IPv6.
RFC2740、IPv6のためのOSPFでこの機能性をカバーしています。
7.4. Experimental RFCs
7.4. 実験的なRFCs
7.4.1. Distance Vector Multicast Routing Protocol (RFC 1075)
7.4.1. ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル(RFC1075)
This protocol is a routing protocol for IPv4 multicast routing. It is no longer in use and need not be redefined.
このプロトコルはIPv4マルチキャストルーティングのためのルーティング・プロトコルです。 それは、もう使用中でなく、再定義される必要はありません。
Olvera & Nesser II Informational [Page 11] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[11ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
7.4.2. An Experiment in DNS Based IP Routing (RFC 1383)
7.4.2. DNSでの実験はIPルート設定を基礎づけました。(RFC1383)
This protocol relies on IPv4 DNS RR, but is no longer relevant has never seen much use; no action is necessary.
このプロトコルがIPv4 DNS RRを当てにしますが、もう関連していない、多くの使用を一度も見たことがありません。 どんな動作も必要ではありません。
7.4.3. Core Based Trees (CBT version 2) Multicast Routing (RFC 2189)
7.4.3. コアBased Trees(CBTバージョン2)マルチキャストルート設定(RFC2189)
This protocol relies on IPv4 IGMP Multicast and a new protocol standard may be produced. However, the multicast routing protocol has never been in much use and is no longer relevant; no action is necessary.
このプロトコルはIPv4 IGMP Multicastを当てにします、そして、新しいプロトコル標準は生産されるかもしれません。 しかしながら、マルチキャストルーティング・プロトコルは、多くの使用で一度もなくて、またもう関連していません。 どんな動作も必要ではありません。
7.4.4. Core Based Trees (CBT) Multicast Routing Architecture (RFC 2201)
7.4.4. コアベースの木(CBT)のマルチキャストルート設定アーキテクチャ(RFC2201)
See previous Section for the limitation in this protocol.
このプロトコルにおける制限に関して前のセクションを見てください。
7.4.5. Intra-LIS IP multicast among routers over ATM using Sparse
Mode PIM (RFC 2337)
7.4.5. Sparse Mode PIMを使用するATMの上のルータの中のイントラ-LIS IPマルチキャスト(RFC2337)
This protocol is designed for IPv4 multicast. However, Intra-LIS IP multicast among routers over ATM is not believed to be relevant anymore. A new mechanism may be defined for IPv6 multicast.
このプロトコルはIPv4マルチキャストのために設計されています。 しかしながら、ATMの上のルータの中のIntra-LIS IPマルチキャストをそれ以上関連させているのは信じられていません。 新しいメカニズムはIPv6マルチキャストのために定義されるかもしれません。
7.4.6. QoS Routing Mechanisms and OSPF Extensions (RFC 2676)
7.4.6. QoSルート設定メカニズムとOSPF拡張子(RFC2676)
QoS extensions for OSPF were never used for OSPFv2, and there seems to be little need for them in OSPFv3.
OSPFのためのQoS拡張子はOSPFv3でOSPFv2に使用して、それらの必要性が決してほとんど見えないということでした。
However, if necessary, an update to this document could simply define the use of the IPv6 Traffic Class field since it is defined to be exactly the same as the IPv4 TOS field.
必要ならしかしながら、それがまさにIPv4 TOS分野と同じになるように定義されるので、このドキュメントへのアップデートは単にIPv6 Traffic Class分野の使用を定義するかもしれません。
8. Security Considerations
8. セキュリティ問題
This document examines the IPv6-readiness of routing specification; this does not have security considerations in itself.
このドキュメントはルーティング仕様のIPv6-準備を調べます。 これには、本来、セキュリティ問題がありません。
9. Acknowledgements
9. 承認
The original author, Philip J. Nesser II, would like to acknowledge the support of the Internet Society in the research and production of this document.
原作者(フィリップJ.Nesser II)は研究における、インターネット協会のサポートとこのドキュメントの生産を承諾したがっています。
He also would like to thanks his partner in all ways, Wendy M. Nesser.
また、彼はありがとうございますたがっています。すべての方法で彼のパートナー、ウェンディーM.Nesser。
Olvera & Nesser II Informational [Page 12] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[12ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
Cesar Olvera would like to thanks Pekka Savola for an extended guidance and comments for the edition of this document, and Jordi Palet for his support and reviews.
セザールオルベラは拡張指導のための感謝ペッカSavola、このドキュメントの版のためのコメント、および彼のサポートとレビューのためのジョルディPaletがそうしたいです。
Additionally, he would further like to thank Andreas Bergstrom, Brian Carpenter, Jeff Haas, Vishwas Manral, Gabriela Medina, Venkata Naidu, Jeff Parker and Curtis Villamizar for valuable feedback.
さらに、彼は有益なフィードバックについてさらにアンドレアス・ベルイストローム、ブライアンCarpenter、Jeff Haas、Vishwas Manral、ガブリエラ・メディナ、Venkataナーイドゥ、ジェフ・パーカー、およびカーティスVillamizarに感謝したがっています。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the
Survey of IPv4 Addresses in Currently Deployed IETF Standards",
RFC 3789, June 2004.
[1] Nesser、II、P.、およびA.ベルイストローム、エディタ、「IPv4の調査への紹介は現在配布しているIETFで規格を扱います」、RFC3789、2004年6月。
[2] Sofia, R. and P. Nesser, II, "Survey of IPv4 Addresses in
Currently Deployed IETF Application Area Standards", RFC 3795,
June 2004.
[2] ソフィア、R.、およびP.Nesser、II、「IPv4の調査は、現在配布しているIETFでアプリケーション部が規格であると扱います」、RFC3795、2004年6月。
[3] Mickles, C. and P. Nesser, II, "Internet Area: Survey of IPv4
Addresses Currently Deployed IETF Standards", RFC 3790, June
2004.
[3]Mickles、C.とP.Nesser、II、「インターネット地域:」 「現在IETF規格であると配布されているIPv4アドレスの調査」、RFC3790、2004年6月。
[4] Nesser, II, P. and A. Bergstrom, "Survey of IPv4 addresses in
Currently Deployed IETF Operations & Management Area
Standards", RFC 3796, June 2004.
[4]NesserとII、P.とA.ベルイストローム、「Currently Deployed IETF Operations&Management Area StandardsのIPv4アドレスの調査」RFC3796(2004年6月)。
[5] Nesser, II, P. and A. Bergstrom. "Survey of IPv4 Addresses in
Currently Deployed IETF Security Area Standards", RFC 3792,
June 2004.
[5] Nesser、II、P.、およびA.ベルイストローム。 「IPv4の調査は、現在配布しているIETFでセキュリティ領域が規格であると扱う」RFC3792、2004年6月。
[6] Nesser, II, P. and A. Bergstrom. "Survey of IPv4 Addresses in
Currently Deployed IETF Sub-IP Area Standards", RFC 3793, June
2004.
[6] Nesser、II、P.、およびA.ベルイストローム。 「IPv4の調査は、現在配布しているIETFサブIPで領域が規格であると扱う」RFC3793、2004年6月。
[7] Nesser, II, P. and A. Bergstrom "Survey of IPv4 Addresses in
Currently Deployed IETF Transport Area Standards", RFC 3794,
June 2004.
「IPv4アドレスの調査は現在、中でIETF輸送領域規格であると配布した」[7]Nesser、II、P.、およびA.ベルイストローム、RFC3794(2004年6月)
10.2. Informative References
10.2. 有益な参照
[8] Chen, E. and J. Yuan, "AS-wide Unique BGP Identifier for BGP-
4", Work in Progress, December 2003.
[8] チェン、E.、およびJ.元、「-広さ、BGP4インチ、処理中の作業のための2003インチ年12月のユニークなBGP識別子。
[9] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress, January
2003.
[9] ホップス、C.、「IPv6を発送する、-、」、1月2003、進行中で、働いてください。
Olvera & Nesser II Informational [Page 13] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[13ページ]のRFC3791IPv4は、2004年6月にIETFでルート設定が領域であると扱います。
[10] Hinden, R., "Virtual Router Redundancy Protocol for IPv6", Work
in Progress, February 2004.
[10]Hinden、R.、「IPv6"のための仮想のルータ冗長プロトコル、進行中の仕事、2004年2月。」
11. Authors' Addresses
11. 作者のアドレス
Please contact the authors with any questions, comments or suggestions at:
いずれをもっている作者のために以下で質問、コメントまたは提案に連絡してください。
Cesar Olvera Morales Researcher Consulintel San Jose Artesano, 1 28108 - Alcobendas Madrid, Spain
1歳の研究者ConsulintelサンノゼArtesanoのセザールオルベラモラレス、28108--アルコベンダスマドリード、スペイン
Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: cesar.olvera@consulintel.es
以下に電話をしてください。 +34 91 151、81 99、Fax: +34 91 151 81 98はメールされます: cesar.olvera@consulintel.es
Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034
ワシントン フィリップJ.Nesser IIのNesser校長とNesserコンサルティング13501第100Ave Ne、#5202カークランド、98034
Phone: +1 425 481 4303 EMail: phil@nesser.com
以下に電話をしてください。 +1 4303年の425 481メール: phil@nesser.com
Olvera & Nesser II Informational [Page 14] RFC 3791 IPv4 Addresses in the IETF Routing Area June 2004
オルベラとNesserのIIの情報[14ページ]のRFC3791IPv4は領域2004年6月にIETFにルート設定を記述します。
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Olvera & Nesser II Informational [Page 15]
オルベラとNesser II情報です。[15ページ]
一覧
スポンサーリンク
