[要約] RFC 3791は、IETFのルーティングエリアの標準トラックおよび実験的なドキュメントで現在使用されているIPv4アドレスの調査に関するものです。このRFCの目的は、IETFのルーティングプロトコルにおけるIPv4アドレスの使用状況を把握し、将来のアドレス割り当てに関する情報を提供することです。
Network Working Group C. Olvera
Request for Comments: 3791 Consulintel
Category: Informational P. Nesser, II
Nesser & Nesser Consulting
June 2004
Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents
現在展開されているIETFルーティングエリア標準の追跡および実験文書におけるIPv4アドレスの調査
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This 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.
この調査作業では、現在展開されているIETFルーティング領域の文書化された標準でIPv4アドレスのすべての使用法を文書化しようとしています。すべてのIPv4インターネットからすべてのIPv6インターネットに正常に移行するために、多くの暫定ステップが実行されます。これらの手順の1つは、IPv4依存関係を持つ現在のプロトコルの進化です。これらのプロトコル（およびその実装）がネットワークアドレスが依存しないように再設計されることが期待されていますが、少なくとも二重にIPv4とIPv6をサポートすることに失敗します。この目的のために、実験的なRFCと同様に、すべての標準（フル、ドラフト、提案）が調査され、依存関係が文書化されます。
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
11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 14
12. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15
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ルーティング領域の文書化された標準で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メイン領域（アプリケーション[2]、インターネット[3]、操作に適合する7つのドキュメントに分割されました。＆Management [4]、ルーティング[このドキュメント]、セキュリティ[5]、Sub-IP [6]、輸送[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].
一般的な概要、文書化中に使用される方法論は、7つのドキュメント全体の調査の範囲を、このドキュメントのセットの導入に記載しています[1]。
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標準の以下のクラスが調査され、完全なドラフト、提案、および実験的です。情報、BCP、歴史的なRFCは対処されていません。新しいバージョンのいずれかによって廃止されたRFC、または標準プロセスを通じて移行した場合には、カバーされていません。
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はそれぞれ、完全なドラフト、提案された標準、実験RFCの生の分析について説明します。各RFCは、RFC 1から始まり、RFC 3100を終了（周り）からターンで説明します。各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に示されているデータの分析です。ここでは、すべての結果が全体として考慮され、後のRFCで解決された問題は相関しています。
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
完全なインターネット標準（最も一般的には「標準」と呼ばれる）は、インターネット全体で広く実装および使用されている完全に成熟したプロトコル仕様です。
RIPv2 is only intended for IPv4 networks.
RIPV2は、IPv4ネットワークを対象としています。
This RFC defines a protocol for IPv4 routing. It is highly assumptive about address formats being IPv4 in nature.
このRFCは、IPv4ルーティングのプロトコルを定義します。これは、アドレス形式が本質的にIPv4であることを非常に仮定します。
RIPv2 is only intended for IPv4 networks.
RIPV2は、IPv4ネットワークを対象としています。
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.
ドラフト標準は、IETFの最後から2番目の標準レベルを表しています。プロトコルは、複数の独立した相互運用可能な実装がある場合にのみ、ドラフト標準を達成できます。ドラフト基準は通常、非常に成熟しており、広く使用されています。
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. RFC 1772インターネットでのボーダーゲートウェイプロトコルの適用
This RFC is a discussion of the use of BGP-4 on the Internet.
このRFCは、インターネットでのBGP-4の使用に関する議論です。
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only.
プロトコルの拡張にはIPv4依存関係はありませんが、ベースプロトコルであるBGP-4はIPv4のみです。
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 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.
提案された標準は、入門レベルの文書です。単一の実装にも要件はありません。多くの場合、提案されていることは、IETF標準プロセスで実装または前進することはありません。したがって、それらは多くの場合、インターネットコミュニティに提示される提案されたアイデアです。欠陥が暴露されることもあれば、問題に対する多くの競合する解決策の1つです。これらの後のケースでは、この議論の目的に役立たないため、議論は提示されません。
This document specifies a protocol for the exchange of IPv4 routing information.
このドキュメントは、IPv4ルーティング情報の交換のためのプロトコルを指定します。
This document discusses a version of OSPF that is limited to IPv4.
このドキュメントでは、IPv4に限定されたOSPFのバージョンについて説明します。
BGP2 and BGP3 are both deprecated and therefore are not discussed in this document.
BGP2とBGP3はどちらも非推奨であるため、このドキュメントでは議論されていません。
The architecture described in this document has no IPv4 dependencies.
このドキュメントで説明されているアーキテクチャには、IPv4依存関係がありません。
There are no IPv4 dependencies in this protocol.
このプロトコルにはIPv4依存関係はありません。
This document deals exclusively with IPv4 addressing issue.
このドキュメントは、IPv4アドレス指定の問題のみを扱っています。
This document deals exclusively with IPv4 addressing issue.
このドキュメントは、IPv4アドレス指定の問題のみを扱っています。
This document deals exclusively with IPv4 addressing issue.
このドキュメントは、IPv4アドレス指定の問題のみを扱っています。
This protocol is an extension to a protocol for exchanging IPv4 routing information.
このプロトコルは、IPv4ルーティング情報を交換するためのプロトコルの拡張機能です。
This document defines the use of IPv4 multicast to an IPv4 only routing protocol.
このドキュメントでは、IPv4マルチキャストの使用をIPv4のみのルーティングプロトコルに定義しています。
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依存関係はありません。
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only.
プロトコルの拡張にはIPv4依存関係はありませんが、ベースプロトコルであるBGP-4はIPv4のみです。
This RFC documents a protocol for exchanging IPv6 routing information and is not discussed in this document.
このRFCは、IPv6ルーティング情報を交換するためのプロトコルを文書化しており、このドキュメントでは説明されていません。
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に限定されます。
This protocol is IPv4 specific, there are numerous references to 32- bit IP addresses.
このプロトコルはIPv4固有であり、32ビットIPアドレスへの多くの参照があります。
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依存関係はありません。
The protocol enhancements have no IPv4 dependencies, even though the base protocol, BGP-4, is IPv4 only routing protocol.
ベースプロトコルであるBGP-4がIPv4のみのルーティングプロトコルであるにもかかわらず、プロトコルの拡張機能にはIPv4依存関係がありません。
This RFC documents IPv6 routing methods and is not discussed in this document.
このRFCは、IPv6ルーティング方法を文書化しており、このドキュメントでは説明されていません。
This document defines an IPv6 specific protocol and is not discussed in this document.
このドキュメントは、IPv6固有のプロトコルを定義し、このドキュメントでは説明していません。
This protocol is only defined for IPv4. The document states in the Appendix:
このプロトコルは、IPv4に対してのみ定義されます。ドキュメントは付録に記載されています：
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は含まれていません。
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のみのルーティングプロトコルです。この仕様は更新されますが、RFC 1966を廃止しません。
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に対してのみルーティング情報を運ぶことができます。このドキュメントでは、BGP-4への拡張機能を定義して、複数のネットワークレイヤープロトコル（IPv6、IPXなどなど）のルーティング情報を運ぶことができます。拡張機能は後方互換です - 拡張機能をサポートするルーターは、拡張機能をサポートしないルーターと相互運用できます。
The document is therefore not examined further in this document.
したがって、このドキュメントはこのドキュメントではこれ以上検討されません。
There are no IPv4 dependencies in this protocol.
このプロトコルにはIPv4依存関係はありません。
The RFC defines an IPv6 only document and is not concerned in this survey.
RFCはIPv6のみのドキュメントを定義しており、この調査では関心がありません。
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only routing protocol.
プロトコルの拡張にはIPv4依存関係はありませんが、ベースプロトコルであるBGP-4はIPv4のみのルーティングプロトコルです。
Although the protocol enhancements have no IPv4 dependencies, the base protocol, BGP-4, is IPv4 only routing protocol.
プロトコルの拡張にはIPv4依存関係はありませんが、ベースプロトコルであるBGP-4はIPv4のみのルーティングプロトコルです。
This document defines an extension to an IPv4 routing protocol.
このドキュメントは、IPv4ルーティングプロトコルの拡張機能を定義します。
There are no IPv4 dependencies in this protocol.
このプロトコルにはIPv4依存関係はありません。
5.29. RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
5.29. RFC 3122逆発見の仕様のためのIPv6ネイバーディスカバリーへの拡張
This is an IPv6 related document and is not discussed in this document.
これはIPv6関連のドキュメントであり、このドキュメントでは説明されていません。
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.
通常、実験的なRFCは、インターネット上の幅広い実装や使用法を持たないプロトコルを定義します。それらはしばしば本質的に礼儀正しさであるか、限られた分野で使用されています。それらは、潜在的な相互運用性またはその他の潜在的な有用なシナリオを可能にするために、インターネットコミュニティに文書化されています。いくつかのケースでは、認められた問題の主流の解決策の代替として提示されています。
This document defines a protocol for IPv4 multicast routing.
このドキュメントは、IPv4マルチキャストルーティングのプロトコルを定義しています。
This proposal is IPv4 limited:
この提案はIPv4 Limitedです。
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レコードには、レコード識別子、コストインジケーター、IPアドレスの3つのフィールドが含まれます。
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|
|_________________________|________|__________|___________________|
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.32.27」から始まるすべてのホストについて、IPホスト "10.0.0.7"はゲートウェイとして使用でき、優先値は10です。
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によって実行可能な設計として放棄されています。このドキュメントでは考慮されていません。
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依存関係はありません。
This protocol is both IPv4 and IPv6 aware and needs no changes.
このプロトコルはIPv4とIPv6の両方であり、変更は必要ありません。
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のみのルーティングプロトコルです。この仕様はRFC 2796によって更新されました。
The document specifies a protocol that depends on IPv4 multicast. There are many packet formats defined that show IPv4 usage.
このドキュメントは、IPv4マルチキャストに依存するプロトコルを指定します。IPv4の使用を示す多くのパケット形式が定義されています。
See previous Section for the IPv4 limitation in this protocol.
このプロトコルのIPv4制限については、前のセクションを参照してください。
This protocol is designed for IPv4 multicast.
このプロトコルは、IPv4マルチキャスト向けに設計されています。
6.10. RFC 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
6.10. RFC 2362 Protocol Independent Multicast-Sparse Mode（PIM-SM）：プロトコル仕様
This protocol is both IPv4 and IPv6 aware and needs no changes.
このプロトコルはIPv4とIPv6の両方であり、変更は必要ありません。
There are IPv4 dependencies in this protocol. It requires the use of the IPv4 TOS header field.
このプロトコルにはIPv4依存関係があります。IPv4 TOSヘッダーフィールドの使用が必要です。
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または44.83％の実験RFCS：11または54.54％のうち6つまたは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.
特定された人のうち、多くは時代遅れで未使用のプロトコルを文書化するため、アクションは必要ありませんが、他の人は適切なワーキンググループによって積極的に更新されているドキュメントプロトコルです。さらに、更新する必要があるが、更新されていない場合は運用上の影響を引き起こさない標準の多くのインスタンスがあります。残りのインスタンスは以下に文書化されています。著者は、他のプロトコル設計者を簡単に参照できる形式で結果を整理しようとしました。声明の割り当ては、著者が更新のニーズを認識していることに完全に基づいており、公式の声明としてとられるべきではありません。
This problem has been fixed by RFC 2081, RIPng Protocol Applicability Statement.
この問題は、RFC 2081、RIPNGプロトコルの適用性ステートメントによって修正されています。
This problem has been fixed by RFC 2740, OSPF for IPv6.
この問題は、IPv6のOSPF RFC 2740によって修正されています。
This problem has been fixed by RFC 2080, RIPng for IPv6.
この問題は、IPv6のRFC 2080、RIPNGによって修正されています。
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のRFC 2858マルチプロトコル拡張、RFC 2545 IPv6間ドメインルーティングのBGP-4マルチプロトコル拡張の使用、および[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.
RFC 2858はBGPを拡張して、他の住所ファミリのルーティング情報を交換できるようにするマルチプロトコル拡張をサポートします。RFC 2545はさらにRFC 2858を拡張してIPv6ルーティング情報を交換することを完全にサポートし、TCP IPv6を輸送メカニズムとして使用して拡張BGP-4プロトコルのサポートをさらに明確にします。完全なIPv6サポートを提供するには、RFC 1771、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-4の更新バージョンを変更することなく、このメモ関数で以前に分析されたすべてのBGP拡張機能も注意してください。
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-ISの使用（RFC 1195）
This problem is being addressed by the IS-IS WG [9].
この問題は、IS-IS WG [9]によって対処されています。
This problem has been resolved in RFC 2740, OSPF for IPv6.
この問題は、IPv6のOSPF RFC 2740で解決されています。
The contents of this specification has been treated in various IPv6 addressing architecture RFCs, see RFC 3513 & 3587.
この仕様の内容は、さまざまなIPv6アドレス指定アーキテクチャRFCで処理されています。RFC3513および3587を参照してください。
The contents of this specification has been treated in various IPv6 addressing architecture RFCs, see RFC 3513 & 3587.
この仕様の内容は、さまざまなIPv6アドレス指定アーキテクチャRFCで処理されています。RFC3513および3587を参照してください。
The contents of this specification has been treated in various IPv6 addressing architecture RFCs, see RFC 3513 & 3587.
この仕様の内容は、さまざまなIPv6アドレス指定アーキテクチャRFCで処理されています。RFC3513および3587を参照してください。
This problem has been addressed in RFC 2080, RIPng for IPv6.
この問題は、RFC 2080、IPv6のRIPNGで対処されています。
This functionality has been covered in RFC 2740, OSPF for IPv6.
この機能は、IPv6のRFC 2740、OSPFでカバーされています。
This functionality has been covered in RFC 2740, OSPF for IPv6.
この機能は、IPv6のRFC 2740、OSPFでカバーされています。
This functionality is provided in RFC 2080, RIPng for IPv6.
この機能は、IPv6のRFC 2080、RIPNGで提供されます。
The problems identified are being addressed by the VRRP WG [10].
特定された問題は、VRRP WG [10]によって対処されています。
This problem has been fixed by RFC 2740, OSPF for IPv6. Opaque options support is an inbuilt functionality in OSPFv3.
この問題は、IPv6のOSPF RFC 2740によって修正されています。OSPFV3の不透明なオプションサポートは、組み込み機能です。
Even though GRE tunneling over IPv6 has been implemented and used, its use has not been formally specified. Clarifications are required.
IPv6を介したGREトンネルが実装および使用されていますが、その使用は正式に指定されていません。説明が必要です。
This functionality has been covered in RFC 2740, OSPF for IPv6.
この機能は、IPv6のRFC 2740、OSPFでカバーされています。
This protocol is a routing protocol for IPv4 multicast routing. It is no longer in use and need not be redefined.
このプロトコルは、IPv4マルチキャストルーティングのルーティングプロトコルです。それはもはや使用されておらず、再定義する必要はありません。
This protocol relies on IPv4 DNS RR, but is no longer relevant has never seen much use; no action is necessary.
このプロトコルはIPv4 DNS RRに依存していますが、もはや重要ではありません。アクションは必要ありません。
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マルチキャストに依存しており、新しいプロトコル標準が生成される場合があります。ただし、マルチキャストルーティングプロトコルはこれまでになく使用されておらず、もはや関連性がありません。アクションは必要ありません。
See previous Section for the limitation in this protocol.
このプロトコルの制限については、前のセクションを参照してください。
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上のルーター間のLIS IPマルチキャストは、もはや関連性があるとは考えられていません。IPv6マルチキャストに対して新しいメカニズムを定義できます。
QoS extensions for OSPF were never used for OSPFv2, and there seems to be little need for them in OSPFv3.
OSPFのQoS拡張機能はOSPFv2に使用されたことはなく、OSPFV3ではほとんど必要としないようです。
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トラフィッククラスフィールドの使用を単純に定義できます。
This document examines the IPv6-readiness of routing specification; this does not have security considerations in itself.
このドキュメントでは、ルーティング仕様のIPv6対応を調べます。これにはセキュリティ上の考慮事項はありません。
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・ネッサーIIは、この文書の研究と制作におけるインターネット協会の支援を認めたいと考えています。
He also would like to thanks his partner in all ways, Wendy M. Nesser.
彼はまた、あらゆる方法で彼のパートナー、ウェンディ・M・ネッサーに感謝したいと思います。
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.
Cesar Olveraは、このドキュメントのエディションの拡張ガイダンスとコメント、Jordi Paletのサポートとレビューについて、Pekka Savolaに感謝したいと思います。
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.
さらに、彼はさらに、貴重なフィードバックをしてくれたアンドレアス・バーグストローム、ブライアン・カーペンター、ジェフ・ハース、ヴィシュワス・マンラル、ガブリエラ・メディナ、ベンカタ・ナイドゥ、ジェフ・パーカー、カーティス・ヴィラミザに感謝したいと思います。
[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. Bergstrom、編集者、「現在展開されているIETF標準におけるIPv4アドレスの調査の紹介」、RFC 3789、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] Sofia、R。およびP. Nesser、II、「現在展開されているIETFアプリケーションエリア標準におけるIPv4アドレスの調査」、RFC 3795、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。and P. Nesser、II、「インターネット領域：IPv4の調査の調査現在展開されているIETF標準」、RFC 3790、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. Bergstrom、「現在展開されているIETFオペレーションおよび管理エリア規格におけるIPv4アドレスの調査」、RFC 3796、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. Bergstrom。「現在展開されているIETFセキュリティエリア標準におけるIPv4アドレスの調査」、RFC 3792、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. Bergstrom。「現在展開されているIETFサブIPエリア標準におけるIPv4アドレスの調査」、RFC 3793、2004年6月。
[7] Nesser, II, P. and A. Bergstrom "Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards", RFC 3794, June 2004.
[7] Nesser、II、P。およびA. Bergstrom「現在展開されているIETF輸送エリア規格におけるIPv4アドレスの調査」、RFC 3794、2004年6月。
[8] Chen, E. and J. Yuan, "AS-wide Unique BGP Identifier for BGP-4", Work in Progress, December 2003.
[8] Chen、E。、およびJ. Yuan、「BGP-4の幅広いBGP識別子」、2003年12月、進行中の作業。
[9] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress, January 2003.
[9] Hopps、C。、「IS-ISを使用したIPv6をルーティング」、2003年1月、進行中の作業。
[10] Hinden, R., "Virtual Router Redundancy Protocol for IPv6", Work in Progress, February 2004.
[10] Hinden、R。、「IPv6の仮想ルーター冗長プロトコル」、2004年2月、進行中の作業。
Please contact the authors with any questions, comments or suggestions at:
質問、コメント、または提案については、著者に連絡してください。
Cesar Olvera Morales Researcher Consulintel San Jose Artesano, 1 28108 - Alcobendas Madrid, Spain
Cesar Olvera Morales Researcher Consulintel San Jose Artesano、1 28108 -Alcobendas Madrid、スペイン
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
EMail: cesar.olvera@consulintel.es
Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034
フィリップJ.ネッサーIIプリンシパルネッサー＆ネッサーコンサルティング13501 100th Ave NE、＃5202 Kirkland、WA 98034
Phone: +1 425 481 4303
EMail: phil@nesser.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。