Network Working Group R. Sofia
Request for Comments: 3795 P. Nesser, II
Category: Informational Nesser & Nesser Consulting
June 2004
Survey of IPv4 Addresses in Currently Deployed
IETF Application Area Standards Track and Experimental Documents
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6.
このドキュメントは、IPv4が二重にIPv4とIPv6をサポートするために、独立した、または少なくともネットワークアドレスになるために再設計と再実装仕様で必要な手順を明確にする試みで依存関係に対処について説明します。この移行は、いくつかの中間段階、それらのいずれかを使用IPアドレス指定のスキーマの種類のフォーマットから独立に現在のIPv4依存仕様の進化であることが必要です。したがって、独立した、または少なくとも二重のIPv4およびIPv6をサポートするためのネットワークアドレスとなるように仕様を再設計し、再実施されることが期待されます。
To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience.
そのステップを実現するためには、すべての現在の標準（フル、ドラフト、提案）が経験したIPv4の依存関係だけでなく、実験的RFCを調査し、文書が必要です。したがって、この文書は、IETFアプリケーション領域は、規格に発生する可能性が文書化展開のIPv4アドレス指定の依存関係を記述しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 10
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 34
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 45
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References. . . . . . . . . . . . . . . . . . 48
10.2. Informative References. . . . . . . . . . . . . . . . . 48
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 50
The exhaustive documentation of IPv4 addresses usage in currently deployed IETF documented standards has now been broken into seven documents conforming to current IETF main areas, i.e., Applications, Internet, Operations and Management, Routing, Sub-IP, and Transport. A general overview of the documentation, as well as followed methodology and historical perspective can be found in [1]. This document represents one of the seven blocks, and its scope is limited to surveying possible IPv4 dependencies in IETF Application Area documented Standards.
IPv4のの徹底的なドキュメントは、現在展開IETF文書化規格での使用を扱う現在IETFの主要分野、すなわち、アプリケーション、インターネット、運用管理、ルーティング、サブIP、および交通に準拠した7つの文書に分割されています。文書の概要、ならびに続く方法と歴史的観点は、[1]に見出すことができます。この文書では、7つのブロックの1つを表しており、その範囲は、基準を文書化IETFアプリケーション領域での可能なIPv4の依存関係を調査に限定されています。
The remainder sections are organized as follows. Sections 3, 4, 5, and 6 describe, respectively, the raw analysis of Internet Standards [2]:
次のように残りのセクションでは、組織化されています。セクション3、4、5、及び6は、それぞれ、インターネット標準[2]の生の分析について説明します。
Full, Draft, and Proposed Standards, and Experimental RFCs. For each section, standards are analysed by their RFC number, in sequential order, i.e., from RFC 1 to RFC 3200. Exceptions to this are some RFCs above RFC 3200. They have been included, given that they obsoleted RFCs within the range 1-3200. Also, the comments presented for each RFC are raw in their nature, i.e., each RFC is simply analysed in terms of possible IPv4 addressing dependencies. Finally, Section 7 presents a global overview of the data described in the previous sections, and suggests possible future steps.
フル、ドラフト、および提案された標準、および実験のRFC。各セクションについて、基準がこれまで3200例外は、彼らは範囲の1-内RFCを廃止することを考えると、含まれているRFC 3200上記のいくつかのRFCいるRFC 1からRFCに、すなわち、順番に、彼らのRFC番号によって分析されます3200。また、各RFCのために提示コメントはその性質において原料である、すなわち、各RFCは、単に依存性をアドレッシング可能のIPv4に関して分析されます。最後に、7節は、前のセクションで説明したデータのグローバルな概要を提示し、将来のステップを示唆しています。
Internet Full Standards have attained the highest level of maturity on the standards track process. They are commonly referred to as "Standards", and represent fully technical mature specifications that are widely implemented and used throughout the Internet.
インターネットのフル規格が標準化トラックプロセスの成熟度の最高レベルを達成しています。彼らは一般的に「基準」と呼ばれ、広く実装とインターネット全体で使用されている、完全に技術的な成熟した仕様を表しています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section 4.1.2 (TRANSFER PARAMETER COMMANDS) describes the port command using the following format:
4.1.2項（転送パラメータコマンド）は、次のフォーマットを使用してポートコマンドについて説明します。
"A port command would be: PORT h1,h2,h3,h4,p1,p2 where h1 is the high order 8 bits of the internet host address."
「portコマンドは次のようになります。h1はインターネットホストアドレスの8ビット高次するポートH1、H2、H3、H4、P1、P2。」
This is a clear reference to an IPv4 address. In sections 4.2.1 and 4.2.2, on reply codes, the code:
これは、IPv4アドレスへの明確な言及です。応答コードのセクション4.2.1と4.2.2において、コード：
"227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)"
"227は、パッシブモード（H1、H2、H3、H4、P1、P2）を入力"
also needs to be reworked for IPv6 addressing. Also, Section 5.3.2 (FTP COMMAND ARGUMENTS) contains:
また、IPv6のアドレッシングに手直しする必要があります。また、5.3.2項（FTPのコマンド引数）が含まれています：
"<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number>
<number> ::= any decimal integer 1 through 255"
This needs to be solved to transition to IPv6.
これは、IPv6への移行を解決する必要があります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
3.18. : SMTP Service Extension for Message Size Declaration
3.18. ：メッセージサイズ宣言のためのSMTPサービス拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Draft Standards is the nomenclature given to specifications that are on the penultimate maturity level of the IETF standards track process. They are considered to be final specifications, which may only experience changes to solve specific problems found. A specification is only considered to be a Draft Standard if there are at least two known independent and interoperable implementations. Hence, Draft Standards are usually quite mature and widely used.
ドラフト規格は、IETFの標準トラックプロセスの最後から二番目の成熟度レベルにある仕様に与えられた命名法です。彼らは唯一見つかった特定の問題を解決するための変更が発生する可能性があり、最終的な仕様であると考えられています。少なくとも二つの既知の独立した相互運用可能な実装がある場合仕様のみドラフト標準であると考えられます。そのため、ドラフト規格は通常、非常に成熟し、広く使用されています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.4. : Network Time Protocol (Version 3) Specification, Implementation
4.4. ：ネットワークタイムプロトコル（バージョン3）仕様、実装
Section 3.2.1 (Common Variables) provides the following variable definitions:
3.2.1項（共通の変数）は、次の変数の定義を提供します。
"Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port (peer.peerport, pkt.peerport): These are the 32-bit Internet address and 16-bit port number of the peer.
「ピアアドレス（peer.peeraddr、pkt.peeraddr）は、ポート（peer.peerport、pkt.peerport）をピア：これらは、32ビットインターネットアドレスとピアの16ビットのポート番号です。
Host Address (peer.hostaddr, pkt.hostaddr), Host Port (peer.hostport, pkt.hostport): These are the 32-bit Internet address and 16-bit port number of the host. They are included among the state variables to support multi-homing."
ホストアドレス（peer.hostaddr、pkt.hostaddr）、ホストポート（peer.hostport、pkt.hostport）：これらは、32ビットのインターネットアドレスとホストの16ビットのポート番号です。これらは、マルチホーミングをサポートするために、状態変数の中に含まれています。」
Section 3.4.3 (Receive Procedure) defines the following procedure:
3.4.3項は、（手順を受信）は、次の手順を定義しています。
"The source and destination Internet addresses and ports in the IP and UDP headers are matched to the correct peer. If there is no match a new instantiation of the protocol machine is created and the association mobilized."
「IP及びUDPヘッダの送信元と宛先のインターネットアドレスとポートが正しいピアに一致している。一致しない場合、プロトコル機械の新しいインスタンスが作成され、関連付けが動員。」
Section 3.6 (Access Control Issues) proposes a simple authentication scheme in the following way:
セクション3.6（アクセス制御の問題）は、以下のように簡単な認証方式を提案しています：
"If a more comprehensive trust model is required, the design can be based on an access-control list with each entry consisting of a 32-bit Internet address, 32-bit mask and three-bit mode. If the logical AND of the source address (pkt.peeraddr) and the mask in an entry matches the corresponding address in the entry and the mode (pkt.mode) matches the mode in the entry, the access is allowed; otherwise an ICMP error message is returned to the requestor. Through appropriate choice of mask, it is possible to restrict requests by mode to individual addresses, a particular subnet or net addresses, or have no restriction at all. The access-control list would then serve as a filter controlling which peers could create associations."
「より包括的な信頼モデルが必要な場合、設計は、32ビットインターネットアドレス、32ビットマスクと3ビットモードからなる各エントリにアクセス制御リストに基づくことができる。論理的な場合、ソースのアドレス（pkt.peeraddr）とエントリマスクは、エントリに対応するアドレスと一致し、モード（pkt.mode）はエントリモードに一致し、アクセスが許可され、そうでない場合、ICMPエラーメッセージが要求元に返されます。マスクの適切な選択によって、個々のアドレスに特定のサブネットまたはネットアドレスをモードによって、要求を制限することが可能である、またはまったく制限がありません。アクセス制御リストは、その後のピアアソシエーションを作成することができ、フィルタ制御手段として役立つであろう。 "
Appendix B Section 3 (B.3 Commands) defines the following command:
付録Bセクション3（B.3コマンド）は、次のコマンドを定義しています。
"Set Trap Address/Port (6): The command association identifier, status and data fields are ignored. The address and port number for subsequent trap messages are taken from the source address and port of the control message itself. The initial trap counter for trap response messages is taken from the sequence field of the command. The response association identifier, status and data fields are not significant. Implementations should include sanity timeouts which prevent trap transmissions if the monitoring program does not renew this information after a lengthy interval."
「設定トラップアドレス/ポート（6）：コマンドのアソシエーション識別子は、ステータス及びデータフィールドは無視され、その後のトラップメッセージのアドレスとポート番号は、制御メッセージ自体の送信元アドレスおよびポートから取られる最初のトラップカウンタの。トラップ応答メッセージは、コマンドのシーケンスフィールドから取得されます。応答アソシエーションID、ステータスとデータフィールドは重要ではない。監視プログラムは、長いインターバルの後、この情報は更新しない場合、実装は、トラップ送信を防ぐサニティ・タイムアウトを含むべきです。」
The address clearly assumes the IPv4 version. Also, there are numerous places in sample code and in algorithms that use the above mentioned variables. It seems that there is no reason to modify the actual protocol. A small number of textual changes and an update to implementations, so they can understand both IPv4 and IPv6 addresses, will suffice to have a NTP version that works on both network layer protocols.
アドレスは明らかにIPv4のバージョンを想定しています。また、サンプルコードおよび上記の変数を使用するアルゴリズムには多くの場所があります。実際のプロトコルを変更する理由はないと思われます。テキストの変更と実装への更新の数が少ない、彼らは、IPv4アドレスとIPv6アドレスの両方を理解することができますので、両方のネットワーク層プロトコル上で動作NTPのバージョンを持っているだけで十分でしょう。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.8. : Multipurpose Internet Mail Extensions (MIME), Part One: Format of Internet Message Bodies
4.8. ：MIME（Multipurpose Internet Mail Extensions）の、第一部：インターネットメッセージ本体のフォーマット
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.10. : MIME, Part Three: Message Header Extensions for Non-ASCII Text
4.10. ：MIME、第三部：非ASCIIテキストのためのメッセージヘッダの拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.11. : MIME Part Five: Conformance Criteria and Examples
4.11. ：MIMEパート5：適合基準と例
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section "Blocksize Option Specification" gives the following example:
セクション「ブロックサイズオプション仕様」は、以下の例を示します：
"For example:
"例えば：
+-------+--------+---+--------+---+--------+---+--------+---+
| 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+
is a Read Request, for the file named "foobar", in octet (binary) transfer mode, with a block size of 1428 octets (Ethernet MTU, less the TFTP, UDP and IP header lengths)."
1428オクテットのブロックサイズを有するオクテット（バイナリ）転送モードで「foobarに」という名前のファイルの読み出し要求、、、（イーサネットMTU、以下TFTP、UDP及びIPヘッダ長）です。」
Clearly, the given blocksize example would not work with IPv6 header sizes, but it has no practical implications, since larger blocksizes are also available.
明らかに、与えられたブロックサイズの例は、IPv6ヘッダサイズでは動作しないだろうが、より大きなブロックサイズも利用可能であるので、それは、実用的な意味を持ちません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.17. : Uniform Resource Identifiers (URI): Generic Syntax
4.17. ：統一資源識別子（URI）：一般的な構文
Section 3.2.2. (Server-based Naming Authority) states:
3.2.2. （サーバーベースのネーミング機関）は述べています：
"The host is a domain name of a network host, or its IPv4 address as a set of four decimal digit groups separated by ".". Literal IPv6 addresses are not supported. ... Note: A suitable representation for including a literal IPv6 address as the host part of a URL is desired, but has not yet been determined or implemented in practice."
「ホストがで区切られた4つの10進数グループのセットとして、ネットワークホスト、またはそのIPv4アドレスのドメイン名である」 "リテラルIPv6アドレスがサポートされていません...注：。。。リテラルIPv6を含むために適切な表現URLのホスト部としてのアドレスが望まれているが、まだ決定したり、実際に実装されていません。」
Section 3.2.2 (http URL) states:
3.2.2（HTTPのURLは）状態：
"The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs.
「『HTTP』スキームはHTTPプロトコル経由でネットワークリソースを見つけるために使用される。このセクションでは、HTTP URLのスキーム固有の構文およびセマンティクスを定義します。
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
HTTP_URL = "HTTP：" "//" ホスト[ "：" ポート] [腹筋_経路の[ ""？クエリ]]
If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (section 5.1.2). The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24])."
ポートが指定された空またはされていない場合、ポート80が仮定されます。セマンティクスは、特定されたリソースは、そのホストのそのポートでTCP接続の待機サーバーに配置されていることであり、資源のためのRequest-URIが腹筋_経路（セクション5.1.2）です。 URLでIPアドレスの使用は（RFC 1900 [24]参照）を可能な限り避けるべきです。」
The text is version neutral, but it is unclear whether individual implementations will support IPv6 addresses. In fact, the use of the ":"separator in IPv6 addresses will cause misinterpretation when parsing URI's. There are other discussions regarding a server recognizing its own IP addresses, spoofing DNS/IP address combinations, as well as issues regarding multiple HTTP servers running on a single IP interface. Again, the text is version neutral, but clearly, such statements represent implementation issues.
テキストは、バージョン中性であるが、個々の実装がIPv6アドレスをサポートするかどうかは不明です。実際には、の使用「：」URIの解析時にIPv6アドレスでのセパレータは、誤解の原因となります。独自のIPアドレス、スプーフィングDNS / IPアドレスの組み合わせ、ならびに単一IPインターフェイス上で実行されている複数のHTTPサーバに関する問題を認識し、サーバーに関する他の議論があります。ここでも、テキストはバージョン中性であるが、明確に、かかる記述は、実装上の問題を表しています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.22. : Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications
4.22. ：配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.23. : The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
4.23. ：メールシステム管理メッセージの報告のための複合/レポートコンテンツタイプ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.25. : An Extensible Message Format for Delivery Status Notifications
4.25. ：配信状態通知のための広げることができるメッセージフォーマット
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Proposed Standards represent initial level documents in the IETF standards track process. They are stable in terms of design, but do not require the existence of implementations. In several cases, these specifications are simply proposed as solid technical ideas, to be analysed by the Internet community, but are never implemented or advanced in the IETF standards process.
提案された標準は、IETF標準トラックプロセスの初期レベルのドキュメントを表します。彼らは、デザインの面で安定しているが、実装の存在を必要としません。いくつかのケースでは、これらの仕様は、単にインターネットコミュニティによって解析されるように、確かな技術思想として提案されているが、IETF標準化プロセスで実装されていないか、高度ありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.2. : Remote Controlled Transmission and Echoing Telnet option
5.2. ：リモコン送信およびエコーTelnetオプション
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section "TTYLOC Number" states:
セクション「TTYLOC数」状態：
"The TTYLOC number is a 64-bit number composed of two (2) 32-bit numbers: The 32-bit official ARPA Internet host address (may be any one of the addresses for multi-homed hosts) and a 32-bit number representing the terminal on the specified host. The host address of [0.0.0.0] is defined to be "unknown", the terminal number of FFFFFFFF (hex, r or-1 in decimal) is defined to be "unknown" and the terminal number of FFFFFFFE (hex, or -2 in decimal) is defined to be "detached" for processes that are not attached to a terminal."
32ビットの公式ARPAインターネットホストアドレス（マルチホームホストのアドレスのいずれでもよい）と32ビットの数値：「TTYLOC数は、2つ（2）32ビット数からなる64ビットの数であります指定されたホスト上の端末を表す。[0.0.0.0]「不明」であると定義され、FFFFFFFF（16進数、RまたはA-1 10進数）の端末番号が「不明」であると定義され、端末のホストアドレスをFFFFFFFE（16進数、または-2 10進数）の数は、端末に接続されていないプロセスの「デタッチ」であると定義されます。」
The clear reference to 32-bit numbers, and to the use of literal addresses in the form [0.0.0.0] is clearly an IPv4-dependency. Thus, the text above needs to be re-written.
32ビットの数値であり、形のリテラルアドレスの使用に関する明確な参照[0.0.0.0]は明らかIPv4の依存性です。したがって、上記のテキストは再書き込みする必要があります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.14. : Telnet Data Entry Terminal option: DODIIS implementation
5.14. ：Telnetのデータ入力端子オプション：DODIIS実装
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.21. : Replication and Distributed Operations extensions to provide an Internet Directory using X.500
5.21. ：X.500を使用してInternet Directoryを提供するために、レプリケーションと分散処理の拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.22. : A File Format for the Exchange of Images in the Internet
5.22. ：インターネットで画像を交換するためのファイル形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Since this document defines a gateway for interaction between FTAM and FTP, the only possible IPv4 dependencies are associated with FTP, which has already been investigated above, in section 3.16.
この文書は、FTAMとFTP間の相互作用のためのゲートウェイを定義するので、唯一の可能なIPv4の依存関係は、既にセクション3.16に、上記検討されているFTP、関連付けられています。
5.26. : Equivalences between 1988 X.400 and Message Bodies
5.26. ：1988 X.400とメッセージ本文の間でそれに相当します
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.27. : Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages
5.27. ：X.400 / 88にX.400 / 84からのメッセージをダウングレードするための規則のMIMEコンテンツタイプは、メッセージの中に存在しているとき
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section 3.1. (Common Internet Scheme Syntax) states:
3.1節。 （共通インターネットスキームの構文）は述べています：
"host The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by ".". Fully qualified domain names take the form as described in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [4]: a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumerical character and possibly also containing "-" characters. The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses."
[13] RFC 1034のセクション3.5で説明したように完全修飾ドメイン名の形式をとる。「。「で区切られた4つの10進数のグループの集合として完全修飾されたネットワークホストのドメイン名またはIPアドレスをホストする」とセクションRFC 1123の2.1 [4]：で区切られたドメインラベルのシーケンスを、各ドメインラベルが始まり、英数文字で終わると、おそらくも含む 『 - 』の文字が一番右のドメインラベルはしかし、数字で始まることはありません「」。 、構文的にIPアドレスからのすべてのドメイン名を区別しています。」
Clearly, this is only valid when using IPv4 addresses. Later in Section 5. (BNF for specific URL schemes), there is the following text:
IPv4のアドレスを使用している場合明らかに、これはのみ有効です。その後、第5節（特定のURLスキームのためのBNF）で、次のテキストがあります：
"; URL schemeparts for ip based protocols:
「; IPベースのプロトコルのURL schemeparts：
ip-schemepart = "//" login [ "/" urlpath ]
IP-schemepart = "//" ログイン[ "/" URLパス]
login = [ user [ ":" password ] "@" ] hostport hostport = host [ ":" port ] host = hostname | hostnumber"
ログイン= [ユーザーの[ "：" パスワード] "@"]ホスト側のHostPort =ホスト[ "：" ポート]ホスト=ホスト名| hostnumber」
Again, this also has implications in terms of IP-version neutrality.
繰り返しますが、これはまた、IP-バージョンの中立性の観点から意味を持っています。
5.32. : MIME Encapsulation of Macintosh Files - MacMIME
5.32. ：MacintoshのファイルのMIMEカプセル化 - のMacMIME
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section 6.5. (Query referral) makes the following statement:
6.5節。 （クエリの紹介は）次の文を作ります：
"When referrals are included in the body of a response to a query, each referral is listed in a separate SERVER-TO-ASK block as shown below.
リフェラルがクエリに対する応答の本体に含まれている場合、以下に示すように、」、各リファーラルは別個SERVER-TO-ASKブロックに記載されています。
# SERVER-TO-ASK Version-number: // version number of index software, used to insure // compatibility Body-of-Query: // the original query goes here Server-Handle: // WHOIS++ handle of the referred server Host-Name: // DNS name or IP address of the referred server Port-Number: // Port number to which to connect, if different from the // WHOIS++ port number"
＃のSERVER-TO-ASKバージョン番号：//互換性のボディ・オブ・クエリーを保証するために使用されるインデックスソフトウェアの//バージョン番号は、：//元のクエリは、ここではサーバー・ハンドルを行く：呼ばサーバーホストの// WHOIS ++ハンドル-name：// DNS名または呼ばサーバーポート番号のIPアドレス：//ポート番号これに接続するには、// WHOIS ++ポート番号」と異なる場合
The syntax used does not present specific IPv4 dependencies, but implementations should be modified to check, in incoming packets, which IP version was used by the original request, so they can determine whether or not to return an IPv6 address.
使用される構文は、特定のIPv4依存性を示さないが、実装は、それらがIPv6アドレスを返却するか否かを決定できるように、IPバージョンは、元の要求によって使用された着信パケットに、チェックするように修正されるべきです。
Section 4 (Caching) states the following:
第4節（キャッシュ）は、次のように述べています：
"A client can cache all information it gets from a server for some time. For example records, IP-addresses of Whois++ servers, the Directory of Services server etc.
「クライアントは、それはいくつかの時間のために、サーバから取得するすべての情報をキャッシュすることができます。例えば、レコードの場合、などのWhois ++サーバ、サービスのディレクトリサーバーのIPアドレス、
A client can itself choose for how long it should cache the information.
クライアント自体は、それが情報をキャッシュする時間のために選択することができます。
The IP-address of the Directory of Services server might not change for a day or two, and neither might any other information."
ディレクトリサービスのサーバーのIPアドレスは、一日か二日のために変更されないことがあります、およびその他の情報がかもしれないでもありません。」
Also, subsection 4.1. (Caching a Whois++ servers hostname) contains:
また、サブセクション4.1。 （Whoisの++サーバのホスト名をキャッシュ）が含まれます。
"An example of cached information that might change is the cached hostname, IP-address and portnumber which a client gets back in a servers-to-ask response. That information is cached in the server since the last poll, which might occurred several weeks ago. Therefore, when such a connection fails, the client should fall back to use the serverhandle instead, which means that it contacts the Directory of Services server and queries for a server with that serverhandle. By doing this, the client should always get the last known hostname.
「変更される可能性があり、キャッシュされた情報の例は、クライアントがサーバツー尋ねる応じて、取り戻すキャッシュされたホスト名、IPアドレスとポート番号です。この情報は、数週間に発生した可能性がある最後のポーリング、以降のサーバにキャッシュされていますこのような接続が失敗したときに前に。そのため、クライアントはそのにserverHandleとサーバーのサービスサーバーとクエリのそれ接点ディレクトリことを意味し、代わりにserverHandleを使用するようにフォールバックする必要があります。これにより、クライアントは常に取得する必要最後の既知のホスト名。
An algorithm for this might be:
このためのアルゴリズムは次のようになります。
response := servers-to-ask response from server A IP-address := find ip-address for response.hostname in DNS connect to ip-address at port response.portnumber if connection fails { connect to Directory of Services server query for host with serverhandle response.serverhandle response := response from Directory of Services server IP-address := find ip-address for response.hostname in DNS connect to ip-address at port response.portnumber if connection fails { exit with error message } } Query this new server"
応答：サーバーA IPアドレスから=のサーバーツー尋ねる応答：接続は、{ホスト用のディレクトリサービスのサーバークエリに接続障害が発生した場合= DNSにresponse.hostnameのIPアドレスを見つけるには、IPアドレスをするために、ポートresponse.portnumberで接続しますserverHandle response.serverhandle応答で：ServicesサーバーIPアドレスのディレクトリから=応答：= DNSでresponse.hostnameのIPアドレスを見つけるIPアドレスをするために接続するポートresponse.portnumberで接続が}クエリ{エラーメッセージで終了}を失敗した場合この新しいサーバ」
The paragraph does not contain IPv4 specific syntax. Hence, IPv6 compliance will be implementation dependent.
段落は、IPv4固有の構文が含まれていません。したがって、IPv6のコンプライアンスは実装依存となります。
5.38. : SMTP Service Extension for Remote Message Queue Starting
5.38. ：リモートメッセージキューの開始のためのSMTPサービス拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.39. : Definition of the URL MIME External-Body Access-Type
5.39. ：URL MIME外部-ボディアクセスタイプの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.40. : SMTP Service Extension for Returning Enhanced Error Codes
5.40. ：拡張エラーコードを返すためのSMTPサービス拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.42. : The Model Primary Content Type for Multipurpose Internet Mail Extensions
5.42. ：多目的インターネットメール拡張のためのモデル主なコンテンツタイプ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.43. : Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)
5.43. ：統一資源識別子を保持するために、X.500属性タイプとオブジェクトクラスの定義（のURI）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section 3 (Description of the VEMMI scheme) states:
第3節（VEMMIスキームの説明は）状態：
"The VEMMI URL scheme is used to designate multimedia interactive services conforming to the VEMMI standard (ITU/T T.107 and ETS 300 709).
「VEMMI URLスキームはVEMMI標準（ITU / T T.107およびETS 300 709）に準拠したマルチメディア双方向サービスを指定するために使用されます。
A VEMMI URL takes the form: vemmi://<host>:<port>/<vemmiservice>; <attribute>=<value>
VEMMI URLの形式をとります。vemmi：// <ホスト>：<ポート> / <vemmiservice>。 <属性> = <値>
as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the port defaults to 575 (client software may choose to ignore the optional port number in order to increase security). The <vemmiservice> part is optional and may be omitted."
3.1節で指定されています。 RFC 1738の場合：<ポート>が省略され、575にポートのデフォルト（クライアントソフトウェアはセキュリティを高めるために、オプションのポート番号を無視することもできます）。 <vemmiservice>部分はオプションであり、省略することができます。」
IPv4 dependencies may relate to the possibility of the <host> portion containing an IPv4 address, as defined in RFC 1738 (see section 5.31. above). Once the problem is solved in the context of RFC 1738, this issue will be automatically solved.
RFC 1738で定義されたIPv4の依存は、（セクション5.31を参照。上記）、IPv4アドレスを含む<ホスト>の部分の可能性に関連し得ます。問題は、RFC 1738のコンテキストで解決されると、この問題は自動的に解決されます。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.49. : Mailbox Names for Common Services, Roles and Functions
5.49. ：メールボックスのCommon Servicesのための名称、機能と役割
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.50. : MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and /MIME
5.50. ：MIXER（MIMEインターネットX.400拡張リレー）：X.400と/ MIMEの間のマッピング
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.51. : Mapping between X.400 and /MIME Message Bodies
5.51. ：X.400および/ MIMEメッセージ本文の間のマッピング
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.55. : Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping
5.55. ：MIXER適合のグローバルアドレスのマッピングを配布するには、インターネットDNSを使用します
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.56. : Use of an X.500/LDAP directory to support MIXER address mapping
5.56. ：X.500 / LDAPディレクトリの使用はMIXERアドレスマッピングをサポートします
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section 7. (Service Type Request Message Format) and Section 9. (Service Registration Message Format) have an 80-bit field from addr-spec (see below) which cannot support IPv6 addresses. Also, Section 20.1. (Previous Responders' Address Specification) states:
第7節（サービスタイプ要求メッセージ形式）と第9節（サービス登録メッセージ形式）は、IPv6アドレスをサポートすることができない（下記参照）のaddrスペックから80ビットのフィールドを持っています。また、セクション20.1。 （前レスポンダアドレス指定）状態：
"The previous responders' Address Specification is specified as
「前回の応答アドレスの指定は次のように指定されています
<Previous Responders' Address Specification> ::=
<addr-spec> |
<addr-spec>, <Previous Responders' Address Specification>
i.e., a list separated by commas with no intervening white space. The Address Specification is the address of the Directory Agent or Service Agent which supplied the previous response. The format for Address Specifications in Service Location is defined in section 20.4. The comma delimiter is required between each <addr-spec>. The use of dotted decimal IP address notation should only be used in environments which have no Domain Name Service."
すなわち、空白が入らないコンマで区切ったリスト。アドレス指定は、前のレスポンスを供給ディレクトリエージェントまたはサービスエージェントのアドレスです。サービスロケーションのアドレス仕様のフォーマットは、セクション20.4で定義されています。コンマ区切り、各<ADDR仕様>との間に必要とされます。ドット付き10進表記のIPアドレス表記の使用は、何のドメインネームサービスを持っていない環境で使用されなければなりません。」
Later, in Section 20.4. (Address Specification in Service Location) there is also the following reference to addr-spec:
その後、セクション20.4インチ（サービス・ロケーションでのアドレス指定）のaddrスペックへの次の参照もあります：
"The address specification used in Service Location is:
「サービスの場所で使用されるアドレス指定は次のとおりです。
<addr-spec> ::= [<user>:<password>@]<host>[:<port>]
<host> ::= Fully qualified domain name |
dotted decimal IP address notation
When no Domain Name Server is available, SAs and DAs must use dotted decimal conventions for IP addresses. Otherwise, it is preferable to use a fully qualified domain name wherever possible as renumbering of host addresses will make IP addresses invalid over time."
何のドメイン・ネーム・サーバーが利用できない場合は、SASおよびDAがIPアドレスのドット十進表記規則を使用する必要があります。それ以外の場合は、ホストアドレスの再番号付けが時間をかけて、IPアドレスが無効になりますよう、可能な限り完全修飾ドメイン名を使用することが好ましいです。」
The whole Section 21. (Protocol Requirements) defines the requirements for each of the elements of this protocol. Several IPv4 statements are made, but the syntax used is sufficiently neutral to apply to the use of IPv6.
全部21（プロトコル要件）は、このプロトコルの各要素のための要件を定義します。いくつかのIPv4のステートメントが作られていますが、使用する構文は、IPv6の使用に適用するために十分に中性です。
Section 22. (Configurable Parameters and Default Values) states:
部22は、（設定可能なパラメータとデフォルト値）状態：
"There are several configuration parameters for Service Location. Default values are chosen to allow protocol operation without the need for selection of these configuration parameters, but other values may be selected by the site administrator. The configurable parameters will allow an implementation of Service Location to be more useful in a variety of scenarios.
「サービスの場所のためのいくつかの設定パラメータがあります。デフォルト値は、これらの設定パラメータの選択を必要とせずにプロトコルの動作を可能にするように選択されているが、他の値は、サイト管理者が選択することができる。設定可能なパラメータは、サービスロケーションの実装ができるようになりますさまざまなシナリオでより有用であること。
Multicast vs. Broadcast All Service Location entities must use multicast by default. The ability to use broadcast messages must be configurable for UAs and SAs. Broadcast messages are to be used in environments where not all Service Location entities have hardware or software which supports multicast.
ブロードキャストすべてのサービスロケーションエンティティ対マルチキャストは、デフォルトでは、マルチキャストを使用する必要があります。ブロードキャストメッセージを使用する能力は、UAとSAのために設定可能でなければなりません。ブロードキャストメッセージはありませんすべてのサービスロケーションエンティティは、マルチキャストをサポートするハードウェアやソフトウェアが存在する環境で使用されるべきです。
Multicast Radius Multicast requests should be sent to all subnets in a site. The default multicast radius for a site is 32. This value must be configurable. The value for the site's multicast TTL may be obtained from DHCP using an option which is currently unassigned."
マルチキャスト半径マルチキャスト要求は、サイト内のすべてのサブネットに送信する必要があります。サイトのデフォルトのマルチキャスト半径は、この値は設定可能でなければならない32です。サイトのマルチキャストTTLの値は、現在割り当てられていないオプションを使用して、DHCPから取得することができます。」
Once again, nothing here precludes IPv6, Section 23.
もう一度、ここでは何もIPv6の、セクション23を排除しません。
(Non-configurable Parameters) states:
（非設定可能なパラメータ）状態：
"IP Port number for unicast requests to Directory Agents:
ディレクトリエージェントへのユニキャスト要求のための「IPポート番号：
UDP and TCP Port Number: 427
UDPとTCPポート番号：427
Multicast Addresses
マルチキャストアドレス
Service Location General Multicast Address: 224.0.1.22
Directory Agent Discovery Multicast Address: 224.0.1.35
A range of 1024 contiguous multicast addresses for use as Service Specific Discovery Multicast Addresses will be assigned by IANA."
サービスの具体的なディスカバリーマルチキャストアドレスとして使用するために1024の連続マルチキャストアドレスの範囲は、IANAによって割り当てられます。」
Clearly, the statements above require specifications related to the use of IPv6 multicast addresses with equivalent functionality.
明らかに、ステートメントは、上記同等の機能を持つIPv6マルチキャストアドレスの使用に関連する仕様を必要としています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.59. : Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
5.59. ：インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
The specification has IPv4 dependencies, as RFC 1738, which is integral to the document, is not IPv6 aware.
仕様は、文書に不可欠であるRFC 1738、としてではなく、IPv6の認識している、IPv4の依存関係を持っています。
Section 6. (Formal Syntax) presents the following statement:
第6節（正式な構文）次の文を提示：
"referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"; See [RFC-1738] for <url> definition"
"referral_response_code = "[" "REFERRAL" 1 *（SPACE <URL>） "]"; <URL>定義" の[RFC-1738]を参照してください
The above presents dependencies on RFC 1738 URL definitions, which have already been mentioned in this document, section 5.31.
上記すでにこの文書に記載されているRFC 1738 URLの定義、セクション5.31への依存性を示しています。
5.62. : A Common Schema for the Internet White Pages Service
5.62. ：インターネットホワイトページサービスのための共通スキーマ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the following example:
4.1節。 （LOGINとAUTHENTICATE照会）以下の例を提供します。
"Example: C: A001 LOGIN MIKE PASSWORD S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user is invalid on this server. Try SERVER2."
"例：C：A001 LOGIN MIKEパスワードS：A001 NO [紹介IMAP：// MIKE @ SERVER2 /]指定されたユーザーは、このサーバー上無効であるSERVER2を試してみてください。"
Even though the syntax "user@SERVER2" is presented often, there are no specifications related to the format of "SERVER2". Hence, it is up to individual implementations to determine acceptable values for the hostname. This may or not include explicit IPv6 addresses.
構文「SERVER2 @ユーザーが」しばしば提示されていても、「SERVER2」の形式に関連した仕様がありません。したがって、ホスト名の許容値を決定するために、個々の実装次第です。これは、明示的なIPv6アドレスを含んでいなくてもよいですか。
5.64. : Simple Hit-Metering and Usage-Limiting for HTTP
5.64. ：HTTP用のシンプルなヒット・メーターと使用制限
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.65. : MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
5.65. ：MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.68. : Using Domains in LDAP/X.500 Distinguished Names
5.68. ：LDAP / X.500識別名にドメインを使用し
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.70. : Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
5.70. ：ライトウェイトディレクトリアクセスプロトコル（v3の）：属性の構文定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.71. : Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
5.71. ：ライトウェイトディレクトリアクセスプロトコル（v3の）：識別名のUTF-8文字列表現
Section 7.1. (Disclosure) states:
7.1節。 （開示）は述べています：
"Distinguished Names typically consist of descriptive information about the entries they name, which can be people, organizations, devices or other real-world objects. This frequently includes some of the following kinds of information:
。「識別名は、通常の人、組織、デバイスまたは他の実世界のオブジェクトすることができ、彼らは名前を付けるエントリについての記述的な情報から構成されこれは、頻繁に、次のような種類の情報の一部が含まれています。
- the common name of the object (i.e., a person's full name) - an email or TCP/IP address - its physical location (country, locality, city, street address) - organizational attributes (such as department name or affiliation)"
- オブジェクトの共通名（すなわち、人のフルネーム） - 電子メールまたはTCP / IPアドレス - その物理的な場所（国、地域、都市、住所） - （例えば部署名や所属など）組織の属性」
This section requires the caveat "Without putting any limitations on the version of the IP address.", to avoid ambiguity in terms of IP version.
このセクションでは、「IPアドレスのバージョンにどんな制限をかけることなく。」警告を必要とし、IPバージョンの用語で曖昧さを避けるために。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
The specification has IPv4 dependencies, as RFC 1738, which is integral to the document, is not IPv6 aware.
仕様は、文書に不可欠であるRFC 1738、としてではなく、IPv6の認識している、IPv4の依存関係を持っています。
5.74. : A Summary of the X.500(96) User Schema for use with LDAPv3
5.74. ：のLDAPv3で使用するためのX.500（96）ユーザスキーマの概要
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.75. : Representing Tables and Subtrees in the X.500 Directory
5.75. ：X.500ディレクトリ内の表やサブツリーを表現
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.76. : Representing the O/R Address hierarchy in the X.500 Directory Information Tree
5.76. ：X.500ディレクトリ情報ツリー内のO / Rアドレスの階層を表現
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.77. : An Extensible Message Format for Message Disposition Notifications
5.77. ：メッセージ処分通知のための広げることができるメッセージフォーマット
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Appendix B, part 2.0.1 (Mandatory Common Part) states:
付録B、パート2.0.1（必須共通部分）が述べています：
"Cache Key This is a database lookup key that uniquely identifies a piece of data which the originator of a CSA Record wishes to synchronize with its peers for a given "Protocol ID/Server Group ID" pair. This key will generally be a small opaque byte string which SCSP will associate with a given piece of data in a cache. Thus, for example, an originator might assign a particular 4 byte string to the binding of an IP address with that of an ATM address. Generally speaking, the originating server of a CSA record is responsible for generating a Cache Key for every element of data that the given server originates and which the server wishes to synchronize with its peers in the SG."
プロトコルID /サーバグループID 『のペア。このキーは、一般的に小さな不透明になる「キャッシュキーは、これは一意にCSAのレコードの創始者は、与えられたためにそのピアと同期したいデータの一部を識別し、データベースの検索キーです』 SCSPは、従って、例えば、発信者がATMアドレスのものとIPアドレスのバインディングを特定の4バイトの文字列を割り当てることができます。キャッシュ内のデータの所定の部分と会合するバイトストリング。一般的に言えば、発信元サーバCSAレコードの指定したサーバが発信され、どのサーバがSG内のピアと同期したいデータのすべての要素のためのキャッシュキーを生成するための責任があります。」
The statement above is simply meant as an example. Hence, any IPv4 possible dependency of this protocol is an implementation issue.
上記のステートメントは、単に例として意図されています。したがって、このプロトコルの任意のIPv4可能な依存性は、実装の問題です。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.84. : The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
5.84. ：メッセージヘッダフィールドを通してコアメールリストコマンドおよびそれらの輸送のためのメタ構文としてのURLの使用
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
In section 7. (TIP Transaction Manager Identification and Connection Establishment):
セクション7.（TIPトランザクションマネージャーの識別および接続確立）：
"The <hostport> component comprises:
「<ホスト側>成分を含みます：
<host>[:<port>]
<ホスト> [：<ポート>]
where <host> is either a <dns name> or an <ip address>; and <port> is a decimal number specifying the port at which the transaction manager (or proxy) is listening for requests to establish TIP connections. If the port number is omitted, the standard TIP port number (3372) is used.
ここで、<ホスト> <DNS名>または<IPアドレス>のいずれかです。そして、<port>は、トランザクション・マネージャ（またはプロキシ）はTIP接続を確立するための要求をリスニングするポートを指定する10進数です。ポート番号が省略された場合、標準的なTIPポート番号（3372）が使用されます。
A <dns name> is a standard name, acceptable to the domain name service. It must be sufficiently qualified to be useful to the receiver of the command.
<DNS名>は、ドメイン名サービスへの許容可能な標準的な名前です。十分にコマンドの受信機に有用であることが認定されなければなりません。
An <ip address> is an IP address, in the usual form: four decimal numbers separated by period characters."
<IPアドレス>は、通常の形で、IPアドレスである：ピリオド文字で区切られた4つの10進数「。
This section has to be re-written to become IP-version neutral. Besides adding a reference to the use of IPv6 addresses, the "host" field should only be defined as a "dns name". However, if the use of literal IP addresses is to be included, the format specified in RFC 2372 has to be followed.
このセクションでは、IP-バージョンは中立になることを再書き込みする必要があります。 IPv6アドレスの使用への参照を追加するほか、「ホスト」フィールドは、「DNS名」として定義する必要があります。リテラルIPアドレスの使用が含まれている場合は、RFC 2372で指定された形式に従わなければなりません。
Later in section 8. (TIP Uniform Resource Locators):
その後、セクション8に（ユニフォームリソースロケータをTIP）：
"A TIP URL takes the form:
「TIPのURLは次の形式をとります。
tip://<transaction manager address>?<transaction string>
ヒント：？// <トランザクションマネージャーアドレス> <トランザクションstring>
where <transaction manager address> identifies the TIP transaction manager (as defined in Section 7 above); and <transaction string> specifies a transaction identifier, which may take one of two forms (standard or non-standard):
（第7上記で定義されるように）<トランザクション・マネージャ・アドレス>は、TIPトランザクションマネージャを識別する。そして、<トランザクションstring>は二つの形式（標準または非標準）のいずれかをとることができ、トランザクション識別子を指定します：
i. "urn:" <NID> ":" <NSS>
私は。 "URN：" <NOT> "：" <NSS>
A standard transaction identifier, conforming to the proposed Internet Standard for Uniform Resource Names (URNs), as specified by RFC2141; where <NID> is the Namespace Identifier, and <NSS> is the Namespace Specific String. The Namespace ID determines the syntactic interpretation of the Namespace Specific String. The Namespace Specific String is a sequence of characters representing a transaction identifier (as defined by <NID>). The rules for the contents of these fields are specified by [6] (valid characters, encoding, etc.).
RFC2141で指定されたユニフォームリソース名（URNの）のために提案されたインターネット標準に準拠した標準トランザクション識別子、。ここで、<NID>名前空間識別子であり、そして<NSS>は、ネームスペース固有の文字列です。名前空間IDは、名前空間固有の文字列の構文解釈を決定します。ネームスペース固有の文字列は、トランザクション識別子を表す文字列（<NID>によって定義される）です。これらのフィールドの内容のための規則は、[6]（有効な文字、符号、等）によって特定されます。
This format of <transaction string> may be used to express global transaction identifiers in terms of standard representations. Examples for <NID> might be <iso> or <xopen>. e.g.,
<トランザクションストリング>のこの形式は、標準的な表現でグローバルトランザクション識別子を発現するために使用されてもよいです。 <NID>の例は、<ISO>または<XOPEN>かもしれません。例えば。、
tip://123.123.123.123/?urn:xopen:xid
ヒント：？//123.123.123.123/のurn：XOPEN：XID
Note that Namespace Ids require registration. See [7] for details on how to do this."
名前空間Idsが登録を必要とすることに注意してください。これを行う方法の詳細については[7]を参照してください。」
There are other references in section 8, regarding the use of literal IP addresses. Therefore, this section also needs to be re-written, and special care should be taken to avoid the use of IP (either IPv4 or IPv6) literal addresses. However, if such use is exemplified, the format specified in RFC 2732 has to be respected.
リテラルIPアドレスの使用に関するセクション8の他の参照があります。したがって、このセクションでは、再書き込みする必要があり、特別なケアはIP（IPv4またはIPv6）のリテラルアドレスの使用を避けるように注意する必要があります。このような使用が例示されている場合は、RFC 2732で指定された形式は尊重されなければなりません。
Section 3. (POP Scheme) states:
第3節（POPスキーム）は述べています：
"A POP URL is of the general form:
「POPのURLは、一般的な形式は次のとおりです。
pop://<user>;auth=<auth>@<host>:<port>
ポップ：// <ユーザー>; AUTH = <認証> @ <ホスト>：<ポート>
Where <user>, <host>, and <port> are as defined in RFC 1738, and some or all of the elements, except "pop://" and <host>, may be omitted."
<ユーザー>、<ホスト>、および<ポート> RFC 1738で定義され、要素の一部または全部を除いているとして「ポップ：//」と<ホスト>、省略することができます「。
RFC 1738 (please refer to section 5.31) has a potential IPv4 limitation. Hence, RFC 2384 will only be IPv6 compliant when RFC 1738 becomes properly updated.
RFC 1738（セクション5.31を参照）電位IPv4の制限を有します。 RFC 1738が適切に更新さになったときしたがって、RFC 2384には、IPv6のみの対応となります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.89. : Feature negotiation mechanism for the File Transfer Protocol
5.89. ：ファイル転送プロトコルの機能ネゴシエーションメカニズム
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.90. : Content-ID and Message-ID Uniform Resource Locators (CIDMID-URL)
5.90. ：コンテンツIDとMessage-IDユニフォームリソースロケータ（CIDMID-URL）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.93. : Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration
5.93. ：トール品質音声 - 32キロビット/秒ADPCMのMIMEサブタイプ登録
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This RFC documents an IPv6 extension and hence, it is not considered in the context of the current discussion.
このRFCはIPv6拡張を文書化し、したがって、それは現在の議論の文脈では考慮されていません。
5.99. : Internet Calendaring and Scheduling Core Object Specification (iCalendar)
5.99. ：インターネットカレンダーとスケジュールのコアオブジェクト仕様（iCalendar形式）
Section 4.8.4.7 (Unique Identifier) states:
セクション4.8.4.7（一意識別子）は述べています：
"Property Name: UID
「プロパティ名：UID
Purpose: This property defines the persistent, globally unique identifier for the calendar component.
目的：この特性は、カレンダーコンポーネントの永続的な、グローバルに一意の識別子を定義します。
Value Type: TEXT
値の種類：TEXT
Property Parameters: Non-standard property parameters can be specified on this property.
プロパティパラメータ：非標準プロパティのパラメータは、このプロパティに指定することができます。
Conformance: The property MUST be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
適合性：プロパティは、「VEVENT」、「VTODO」の「VJOURNAL」または「VFREEBUSY」カレンダー・コンポーネントを指定しなければなりません。
Description: The UID itself MUST be a globally unique identifier. The generator of the identifier MUST guarantee that the identifier is unique. There are several algorithms that can be used to accomplish this. The identifier is RECOMMENDED to be the identical syntax to the [RFC 822] addr-spec. A good method to assure uniqueness is to put the domain name or a domain literal IP address of the host on which the identifier was created on the right hand side of the "@", and on the left hand side, put a combination of the current calendar date and time of day (i.e., formatted in as a DATE-TIME value) along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number). Using a date/time value on the left hand side and a domain name or domain literal on the right hand side makes it possible to guarantee uniqueness since no two hosts should be using the same domain name or IP address at the same time. Though other algorithms will work, it is RECOMMENDED that the right hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can guarantee the uniqueness of the left hand side within the scope of that domain."
説明：UID自体がグローバル一意識別子でなければなりません。識別子のジェネレータは、識別子が一意であることを保証しなければなりません。これを実現するために使用することができ、いくつかのアルゴリズムがあります。識別子は、[RFC 822] ADDR仕様と同一の構文ことが推奨されます。一意性を保証するための良い方法は、ドメイン名または識別子は、「@」の右側に、そして左側に作成されたホストのドメインリテラルIPアドレスを置くの組み合わせを置くことです（例えば、プロセスID番号）システム上で利用可能ないくつかの他の現在のユニークな（おそらくシーケンシャル）識別子と共にその日の現在のカレンダー日付と時刻（すなわち、日付時刻値としてフォーマットされました）。何の2つのホストが同時に同じドメイン名またはIPアドレスを使用してはならないので、右側のリテラルの左側の日付/時刻値とドメイン名またはドメインを使用すると、一意性を保証することが可能となります。他のアルゴリズムが動作するが、右手側は、メッセージ識別子のジェネレータは、そのドメインの範囲内で左側の一意性を保証することができるいくつかのドメイン識別子（ホスト自体または他の方法のいずれか）ように含有することが推奨されます。」
Although the above does not explicitly state the use of IPv4 addresses, it addresses the explicit use of RFC 822 (obsoleted by RFC 2822). To become IPv6 compliant it should follow the guidelines for RFC 2822 (see section 5.129).
上記の明示的IPv4アドレスの使用を述べるものではないが、それは、RFC 822（RFC 2822によって廃止）の明示的な使用に対処します。 IPv6は、それはRFC 2822のためのガイドラインに従う必要があり準拠になるために（セクション5.129を参照してください）。
5.100. : iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries
5.100。 ：iCalendarの輸送に依存しない相互運用性プロトコル（のiTIP）スケジューリングイベント、空き時間、TO-DOSと仕訳
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.101. : iCalendar Message-Based Interoperability Protocol (iMIP)
5.101。 ：iCalendarのメッセージベースの相互運用性プロトコル（iMIPの）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This RFC contains several discussions on the usage of IP Address authorization schemes, but it does not limit those addresses to IPv4.
このRFCはIPアドレスの認証スキームの使用に関するいくつかの議論が含まれていますが、それは、IPv4にこれらのアドレスを制限するものではありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.106. : Indicating Supported Media Features Using Extensions to DSN and MDN
5.106。 ：サポートを示すメディアはDSNとMDNに拡張機能を使用しています
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.111. : MIME Encapsulation of Aggregate Documents, such as HTML
5.111。 ：HTMLなどの集計文書のMIMEカプセル化
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.112. : Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
5.112。 ：ライトウェイトディレクトリアクセスプロトコル（v3の）：動的なディレクトリサービスのための拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section 8.1. (Service Request) contains the following:
8.1節。 （サービスリクエスト）次のものが含まれます。
"
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
。。。
<PRList> is the Previous Responder List. This <string-list> contains dotted decimal notation IP (v4) addresses, and is iteratively multicast to obtain all possible results (see Section 6.3). UAs SHOULD implement this discovery algorithm. SAs MUST use this to discover all available DAs in their scope, if they are not already configured with DA addresses by some other means."
<PRList>前のレスポンダ一覧です。この<文字列リスト>は、ドット十進表記のIP（V4）のアドレスが含まれており、すべての可能な結果を得るために反復的にマルチキャストである（6.3節を参照してください）。 UAはこの発見アルゴリズムを実装する必要があります。 SAは、彼らはすでにいくつかの他の手段でDAアドレスが設定されていない場合は、その範囲内のすべての利用可能なDAを発見するために、これを使用しなければなりません。」
And later:
以降：
"A SA silently drops all requests which include the SA's address in the <PRList>. An SA which has multiple network interfaces MUST check if any of the entries in the <PRList> equal any of its interfaces. An entry in the PRList which does not conform to an IPv4 dotted decimal address is ignored: The rest of the <PRList> is processed normally and an error is not returned."
「A SAは静か<PRList>におけるSAのアドレスを含むすべての要求を廃棄します。<PRList>の項目のいずれかは、そのインターフェイスのいずれかに等しい場合は、複数のネットワークインタフェースを有するアンSAをチェックしなければならない。行いPRListのエントリ小数アドレスを点線のIPv4に準拠していませ無視されます。<PRList>の残りの部分は正常に処理され、エラーが返されていません「。
To become IPv6 compliant, this protocol requires a new version.
IPv6対応になるには、このプロトコルは、新しいバージョンが必要です。
Section 2.1. (Service URL Syntax) defines:
2.1. （サービスURL構文）を定義します：
"The ABNF for a service: URL is:
「サービスのABNF：URLは次のとおりです。
hostnumber = ipv4-number ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)"
（ "" 1 * 3digit）3 = 1 * 3digit書き込み可能=たIPv4-IPv4の書き込み可能な書き込み可能なホスト」
This document presents many other references to hostnumber, which requires an update to support IPv6.
この文書は、IPv6をサポートするために更新が必要hostnumber、と他の多くの参照を提供します。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.118. : ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses
5.118。 ：動的IPアドレスを持つON-DEMAND MAIL RELAY（ODMR）SMTP
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.120. : The Architecture of the Common Indexing Protocol (CIP)
5.120。 ：一般的なインデックスプロトコルのアーキテクチャ（CIP）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.121. : MIME Object Definitions for the Common Indexing Protocol
5.121。 ：一般的なインデックスプロトコルのためのMIMEオブジェクト定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This document defines an IPv6 specific protocol and hence, it is not discussed in this document.
この文書は、IPv6特定のプロトコルを定義し、したがって、それは本書では説明しません。
5.124. : Corrections to "A Syntax for Describing Media Feature Sets"
5.124。 ：「メディア機能セットの記述のための構文」の訂正
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
The specification discusses A records at length, and the MX record handling with the different combinations of A and AAAA records and IPv4/IPv6-only nodes might cause several kinds of failure modes.
仕様は、長さでレコードを説明し、そしてAおよびAAAAレコードとIPv4 / IPv6専用ノードの異なる組み合わせで処理MXレコードは、故障モードのいくつかの種類が発生する可能性があります。
Section 3.4.1 (Addr-spec specification) contains:
3.4.1項（アドレススペック仕様）が含まれています：
"The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [STD3, STD13, STD14]. In the domain-literal form, the domain is interpreted as the literal Internet address of the particular host. In both cases, how addressing is used and how messages are transported to a particular host is covered in the mail transport document [RFC2821]. These mechanisms are outside of the scope of this document.
「ドメイン部分は、メールが配信される点を識別する。[STD3、STD13、STD14]に記載されているようにドット原子の形態では、これはインターネットドメイン名（ホスト名またはメール交換名のいずれか）として解釈され。ドメインリテラル形態では、ドメインは、アドレッシングを使用する方法、両方の場合において、特定のホストの文字通りのインターネットアドレスとして解釈され、メッセージが特定のホストに輸送する方法メール転送文書[RFC2821]で覆われています。これらのメカニズムはこの文書の範囲外です。
The local-part portion is a domain dependent string. In addresses, it is simply interpreted on the particular host as a name of a particular mailbox."
ローカル部分部分はドメイン依存文字列です。アドレスでは、単に特定のメールボックスの名前として特定のホスト上で解釈されます。」
Literal IP addresses should be avoided. However, in case they are used, there should be a reference to the format described in RFC 2732.
リテラルIPアドレスは避けるべきです。しかし、それらが使用される場合には、RFC 2732に記述されたフォーマットへの参照があるべきです。
5.129. : GSTN Address Element Extensions in E-mail Services
5.129。 ：GSTNは、Eメールサービスに要素拡張アドレス
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.130. : The LDAP Data Interchange Format (LDIF) - Technical Specification
5.130。 ：LDAPデータ交換フォーマット（LDIF） - 技術仕様
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.133. : LDAP Control Extension for Server Side Sorting of Search Results
5.133。 ：検索結果のサーバサイドソーティングのためのLDAP制御拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.134. : Internet Printing Protocol/1.1: Encoding and Transport
5.134。 ：インターネット印刷プロトコル/ 1.1：コード化と輸送
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.135. : Internet Printing Protocol/1.1: Model and Semantics
5.135。 ：インターネット印刷プロトコル/ 1.1：モデルとセマンティクス
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.137. : MIME Content Types in Media Feature Expressions
5.137。 ：メディア特徴式でのMIMEコンテンツタイプ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.138. : List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
5.138。 ：リスト-ID：メーリングリストの識別のための構造化フィールドと名前空間
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This document includes several references to host IP addresses, but there is no explicit mention to a particular protocol version. A caveat similar to "Without putting any limitations on the version of the IP address." should be added, so that there will remain no doubts about possible IPv4 dependencies.
この文書では、IPアドレスをホストするには、いくつかの言及が含まれていますが、特定のプロトコルバージョンへの明示的な言及はありません。 「IPアドレスのバージョンにどんな制限をかけることなく。」と同様の注意点可能なIPv4の依存関係についての疑問が残らないように、追加する必要があります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.142. : Registration of Charset and Languages Media Features Tags
5.142。 ：文字セットと言語メディアの登録はタグ機能します
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section 6.2.1. (DNS Server Address) states:
6.2.1. （DNSサーバアドレス）が述べています：
"The dnsServerAddress element represents the IP address of the Domain Name Service (DNS) server which should be used when connected to this POP.
「dnsServerAddress要素は、このPOPに接続するときに使用する必要があるドメインネームサービス（DNS）サーバーのIPアドレスを表します。
The address is represented in the form of a string in dotted-decimal notation (e.g., 192.168.101.1).
アドレスはドット付き十進表記（例えば、192.168.101.1）内の文字列の形で表されています。
Syntax: <!-- Domain Name Server IP address --> <!ELEMENT dnsServerAddress (#PCDATA)> <!ATTLIST dnsServerAddress value NOTATION (IPADR) #IMPLIED>"
構文：<！ - ドメインネームサーバのIPアドレス - > <！ELEMENT dnsServerAddress（#PCDATA）> <！ATTLIST dnsServerAddress値表記（IPADR）#IMPLIED>」
Additionally, it is stated in Section 6.2.9. (Default Gateway Address):
さらに、それは、セクション6.2.9に記載されています。 （デフォルトゲートウェイアドレス）：
"The defaulttGatewayAddress element represents the address of the default gateway which should be used when connected to this POP. The address is represented in the form of a string in dotted-decimal notation (e.g., 192.168.101.1).
「defaulttGatewayAddress要素は、このPOPに接続するときに使用されるべきデフォルトゲートウェイのアドレスを表す。アドレスはドット付き十進表記（例えば、192.168.101.1）内の文字列の形で表されています。
Syntax: <!-- Default Gateway IP address (in dotted decimal notation) --> <!ELEMENT defaultGatewayAddress (#PCDATA)> <!ATTLIST defaultGatewayAddress value NOTATION (IPADR) #IMPLIED>"
構文：<！ELEMENT defaultGatewayAddress（#PCDATA）> <！ - - デフォルトゲートウェイのIPアドレス（ドット区切り表記の）> <！ATTLIST defaultGatewayAddress値表記（IPADR）#IMPLIED>」
It should be straightforward to implement elements that are IPv6 aware.
認識してIPv6をしている要素を実装するのは簡単でなければなりません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.147. : SMTP Service Extensions for Transmission of Large and Binary MIME Messages
5.147。 ：大とバイナリMIMEメッセージの送信のためのSMTPサービス拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.148. : TN3270E Service Location and Session Balancing
5.148。 ：TN3270Eサービスロケーションとセッションバランシング
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.149. : Attribute List Extension for the Service Location Protocol
5.149。 ：サービスロケーションプロトコルの属性リスト拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.150. : The Blocks Extensible Exchange Protocol Core (BEEP)
5.150。 ：ブロック拡張可能交換プロトコルコア（BEEP）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This is an IPv6 related document and is not discussed in this document.
これは、IPv6関連の文書であり、この文書で説明されていません。
5.153. : Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
5.153。 ：タグイメージファイル形式（TIFF） - 画像/ TIFFのMIMEサブタイプ登録
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.154. : Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application
5.154。 ：ダイナミックな委譲発見システム（DDDS）第四部：統一資源識別子（URI）解像度アプリケーション
This specification has no explicit dependency on IPv4. However, when referring to the URI format specified in RFC 2396 (see section 4.3. flags, first paragraph), a reference to RFC 2732 should be also added.
この仕様は、IPv4での明示的な依存関係を持っていません。 （セクション4.3を参照。フラグ、最初の段落）RFC 2396で指定されたURIの形式に言及する場合しかし、RFC 2732への参照も追加しなければなりません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Experimental RFCs belong to the category of "non-standard" specifications. This group involves specifications considered "off-track", e.g., specifications that haven't yet reach an adequate standardization level, or that have been superseded by more recent specifications.
実験的RFCは、「非標準」仕様のカテゴリに属します。このグループは、「オフトラック」とみなさ仕様、まだ十分な標準化のレベルに達していない、またはより最近の仕様に取って代わられていることなど、仕様を必要とします。
Experimental RFCs represent specifications that are currently part of some research effort, and that 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 of an acknowledged problem.
実験的RFCは現在、いくつかの研究努力の一部である仕様を表し、それは多くの場合、本質的に妥当であるか、あるいは限られた競技場で使用されます。彼らは、潜在的な相互運用性またはいくつかの他の潜在的に有用なシナリオを可能にするためにインターネットコミュニティに文書化されています。いくつかのケースでは、彼らは認め問題の主流ソリューションの代替として提示されています。
Section 3.1 (Request Messages) contains:
3.1節（リクエスト・メッセージ）が含まれています：
"<Who-Anywhere-Provides?> This message parallels the <Who-Provides?> message with the "third-party" variant described above. The confirming host is required to return at least its own IP address (if it provides the named resource) as well as the IP addresses of any other hosts it believes may provide the named resource. The confirming host though, may never return an IP address for a resource which is the same as an IP address listed with the resource name in the request message. In this case it must treat the resource as if it was unsupported at that IP address and omit it from any reply list.
上記のサードパーティ製の 『変異体「<誰が-どこでも提供し？>このメッセージは、と<誰が提供し？>メッセージに匹敵する』。確認したホストは、それが名前の提供している場合（少なくとも、自身のIPアドレスを返すように要求されリソース）ならびに任意の他のホストのIPアドレス、それは名前のリソースを提供することができる。確認ホストにかかわらず、要求にリソース名で記載されているIPアドレスと同じであるリソースのIPアドレスを返すことはありませんことと考えていますメッセージ。それがそのIPアドレスでサポートされていないかのようにこの場合は、それがリソースを扱わなければなりませんし、任意の応答リストからそれを省略します。
<Does-Anyone-Provide?> This message parallels the <Do-You-Provide?> message again with the "third-party" variant described above. As before, the confirming host is required to return its own IP address as well as the IP addresses of any other hosts it believes may provide the named resource and is prohibited from returning the same IP address in the reply resource specifier as was listed in the request resource specifier. As in the <Do-You-Provide?> case and for the same reason, this message also may not be broadcast."
<-誰でも-提供していますか？>このメッセージは、上記の「サードパーティ」バリアントで再び<-あなたは-提供していますか？>メッセージに匹敵します。前述のように、確認のホストは、自身のIPアドレスだけでなく、それが名前のリソースを提供することができると考えているとに記載されていたとして、応答リソース指定子に同じIPアドレスを返すことから禁止されている任意の他のホストのIPアドレスを返すように要求されリソースの指定を要求します。 <-あなた-提供していますか？>の場合と同じ理由のように、このメッセージも放送されないことがあります。」
Throughout this section, there are several other references to IP address. To avoid ambiguity, a reference to IPv6 addressing should be added.
このセクションを通じて、IPアドレスに他のいくつかの参照があります。あいまいさを避けるために、IPv6アドレスへの参照を追加する必要があります。
Section 4.1. (Resource Lists) presents the following qualifier format:
4.1節。 （リソースリスト）は、次の修飾子の形式を提示します：
"In addition, resource specifiers in all <Who-Anywhere-Provides?>, <Does-Anyone-Provide?> and <They-Provide> messages also contain an additional qualifier following the <Protocol-ID>. This qualifier has the format
「また、<-どこでも提供し、誰？>全て、内のリソース指定子<-誰でも-提供していますか？>と<彼らが-提供>メッセージも<プロトコル-ID>次の追加の修飾子が含まれています。この修飾子は、フォーマットを持っています
+--------+--------+--------+--------+---//---+
| | |
|IPLength| IP-Address-List |
| | |
+--------+--------+--------+--------+---//---+
where
どこ
<IPLength> is the number of IP addresses containing in the following <IP-Address-List> (the <IP-Address-List> field thus occupies the last 4*<IPLength> octets in its resource specifier). In request messages, this is the maximum number of qualifying addresses which may be included in the corresponding reply resource specifier. Although not particularly useful, it may be 0 and in that case provides no space for qualifying the resource name with IP addresses in the returned specifier. In reply messages, this is the number of qualifying addresses known to provide the resource. It may not exceed the number specified in the corresponding request specifier. This field may not be 0 in a reply message unless it was supplied as 0 in the request message and the confirming host would have returned one or more IP addresses had any space been provided.
<IPLength>次の<IPアドレス・リスト>に含むIPアドレスの数は（<IP-アドレス・リスト>フィールドは、このようにそのリソース指定子で最後の4 * <IPLength>オクテットを占めている）です。要求メッセージでは、これは、対応する応答リソース指定子に含まれていてもよい適格アドレスの最大数です。特に有用ではないが、それは0とすることができ、その場合に返された指定子でIPアドレスを持つリソース名を修飾するためのスペースを提供していません。応答メッセージでは、これは、リソースを提供することが知ら予選アドレスの数です。これは、対応する要求指定子で指定された数を超えてはなりません。それは要求メッセージに0として供給されたと任意のスペースが提供されていた確認したホストが1つまたは複数のIPアドレスを返していた場合を除き、このフィールドには、応答メッセージには0ではないかもしれません。
<IP-Address-List> is a list of four-octet IP addresses used to qualify the resource specifier with respect to those particular addresses. In reply messages, these are the IP addresses of the confirming host (when appropriate) and the addresses of any other hosts known to provide that resource (subject to the list length limitations). In request messages, these are the IP addresses of hosts for which resource information may not be returned. In such messages, these addresses should normally be initialized to some "harmless" value (such as the address of the querying host) unless it is intended to specifically exclude the supplied addresses from consideration in any reply messages."
<IP-アドレス-一覧>それらの特定のアドレスに関しては、リソース指定子を修飾するために使用される4オクテットのIPアドレスのリストです。応答メッセージでは、これらは、確認ホスト（適切な場合）のIPアドレスとそのリソース（リストの長さの制限を受ける）を提供することが知られている任意の他のホストのアドレスです。要求メッセージでは、これらは、リソース情報が返されない可能性があるため、ホストのIPアドレスです。具体的に任意の応答メッセージに考慮から供給されたアドレスを除外することを意図されていない限り、そのようなメッセージでは、これらのアドレスは、通常、（例えばクエリホストのアドレスのような）いくつかの「無害」の値に初期化されなければなりません。」
This section requires re-writing considering the 128-bit length of IPv6 addresses, and will clearly impact implementations.
このセクションでは、IPv6アドレスの128ビット長を考慮し再書き込みを必要とし、明確な実装に影響を与えます。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.3. : The Q Method of Implementing TELNET Option Negotiation
6.3. ：実装TELNETオプションのネゴシエーションのQ方法
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.5. : Network Time Protocol (NTP) over the OSI Remote Operations Service
6.5. ：OSIリモート操作サービスオーバーネットワークタイムプロトコル（NTP）
The only dependency this protocol presents is included in Appendix A (ROS Header Format):
このプロトコルは、提示のみ依存性は、付録A（ROSヘッダー形式）に含まれています：
"ClockIdentifier ::= CHOICE {
referenceClock[0] PrintableString,
inetaddr[1] OCTET STRING,
psapaddr[2] OCTET STRING
}"
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Section "Protocol Specification" provides the following example, for the Initial Handshake:
セクション「プロトコル仕様は、」初期ハンドシェイクのために、以下の例を提供します。
"The ticket server replies with a "This is Your Ticket" (TIYT) packet containing the ticket. Figure 2 shows the format of this packet.
これは、チケットを含むチケット 『（TIYT）パケットである。図2は、このパケットのフォーマットを示している。「チケットサーバは、との返答します』
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'T' | 'I' | 'Y' | 'T' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "ticket" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BLKSZ (by default 512) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILSZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address of CFDP server (network order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client UDP port# (cfdpcln) | server UDP port# (cfdpsrv) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 2: "This Is Your Ticket" packet."
図2：パケット「これはあなたのチケットです」「。
This protocol assumes IPv4 multicast, but could be converted to IPv6 multicast with a little effort.
このプロトコルは、IPv4マルチキャストを前提としていますが、少しの努力でのIPv6マルチキャストに変換することができました。
This protocol specifies a protocol that assumes IPv4, but does not actually have any limitations which would limit its operation in an IPv6 environment.
このプロトコルは、IPv4を前提としたプロトコルを指定しますが、実際のIPv6環境での動作を制限する任意の制限はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.12. : SIFT/UFT: Sender-Initiated/Unsolicited File Transfer
6.12. ：/ UFTをSIFT：送信者が開始/迷惑ファイル転送
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are only two specific IPv4 addressing references. The first is presented in Section 6.2. (Command Response):
リファレンスを扱う唯一の2つの特定のIPv4があります。最初は、6.2節で提示されます。 （コマンド応答）：
"203 RPL_TRACEUNKNOWN "???? <class> [<client IP address in dot form>]""
"203 RPL_TRACEUNKNOWN" ???? <クラス> [<ドット形式でクライアントのIPアドレス>] ""
The second appears in Section 8.12 (Configuration File):
第二は、セクション8.12（設定ファイル）に表示されます。
"In specifying hostnames, both domain names and use of the 'dot' notation (127.0.0.1) should both be accepted."
「ホスト名を指定して、 『ドット』表記（127.0.0.1）の両方のドメイン名と使用の両方が受け入れなければなりません。」
After correcting the above, IPv6 support can be added straightforwardly.
上記補正した後、IPv6のサポートが直接的に添加することができます。
6.14. : Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing
6.14. ：スタティックルーティングのためのマルチプロトコル/マルチネットワーク環境テーブル形式V3の中のX.400 MHSサービスのためのルーティングコーディネーション
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.16. : Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures
6.16. ：TPC.INTサブドメインのための動作原理：リモート印刷 - 技術手続き
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.17. : Representing IP Information in the X.500 Directory
6.17. ：X.500ディレクトリにIP情報を表します
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This document defines a method for overcoming FTP IPv4 limitations and is therefore both IPv4 and IPv6 aware.
この文書は、FTP IPv4の限界を克服するための方法を定義し、したがって、IPv4とIPv6の両方が認識しています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.22. : MHS use of the X.500 Directory to support MHS Routing
6.22. ：MHSルーティングをサポートするために、X.500ディレクトリのMHS使用
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.24. : Communicating Presentation Information in Internet Messages: The Content-Disposition Header
6.24. ：インターネット・メッセージでプレゼンテーション情報を伝える：のContent-Dispositionヘッダー
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.29. : Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol
6.29. ：拡張簡易ファイル転送プロトコルを使用して、無線リンクのための簡単なファイル転送プロトコルを用いた実験
This protocol is IPv4 dependent, as can be seen from the segment presented below, taken from Section 2. (PROTOCOL DESCRIPTION):
セクション2（プロトコル記述）から採取した以下に示すセグメントから分かるように、このプロトコルは、IPv4の依存です。
"Table 3: ETFTP Data Encapsulation
「表3：ETFTPデータのカプセル化
+------------+------------+------------+------------+-----------+
|Ethernet(14)| | |ETFTP/ | |
|SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) |
|AX.25(20) | | | | |
+------------+------------+------------+------------+-----------+"
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This protocol is limited to IPv4 multicast. It is expected that a similar functionality could be implemented on top of IPv6 multicast.
このプロトコルは、IPv4マルチキャストに制限されています。同様の機能がIPv6マルチキャストの上に実装できることが期待されています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.36. : MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail
6.36. ：MAXIM-11 - X.400 /インターネットメールとメール-11メールの間のマッピング
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.37. : A Trivial Convention for using HTTP in URN Resolution
6.37. ：URNの解決にHTTPを使用するための些細なコンベンション
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.40. : HTTP Remote Variant Selection Algorithm RVSA/1.0
6.40. ：HTTP遠隔バリアント選択アルゴリズムRVSA / 1.0
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.41. : An Approach for Using LDAP as a Network Information Service
6.41. ：ネットワーク情報サービスとしてLDAPを使用するためのアプローチ
This protocol assumes IPv4 addressing in its schema, as shown in Section 3. (Attribute definitions):
セクション3（属性定義）に示すように、このプロトコルは、IPv4のは、そのスキーマ内のアドレス指定を前提としています。
"( nisSchema.1.19 NAME 'ipHostNumber' DESC 'IP address as a dotted decimal, eg. 192.168.1.1, omitting leading zeros' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String{128}' )
「（nisSchema.1.19 NAME 'ipHostNumber' DESC '点線小数としてIPアドレス、例えば192.168.1.1、省略先行ゼロ' 平等caseIgnoreIA5Match SYNTAX 'IA5String {128}'）
( nisSchema.1.20 NAME 'ipNetworkNumber' DESC 'IP network as a dotted decimal, eg. 192.168, omitting leading zeros' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String{128}' SINGLE-VALUE )
（nisSchema.1.20 NAME 'ipNetworkNumber' DESC '点線小数としてIPネットワーク、例えば192.168、省略先行ゼロ' 平等caseIgnoreIA5Match SYNTAX 'IA5String {128}単一値）
( nisSchema.1.21 NAME 'ipNetmaskNumber' DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, omitting leading zeros' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String{128}' SINGLE-VALUE )"
（nisSchema.1.21 NAME 'ipNetmaskNumber' DESC '点線小数としてIPネットマスク、例えば255.255.255.0、省略先行ゼロ' 平等caseIgnoreIA5Match SYNTAX 'IA5String {128} SINGLE-VALUE）」
The document does try to provide some IPv6 support as in Section 5.4. (Interpreting Hosts and Networks):
文書は、5.4節のように、いくつかのIPv6サポートを提供しようとしません。 （ホストおよびネットワークの解釈）：
"Hosts with IPv6 addresses MUST be written in their "preferred" form as defined in section 2.2.1 of [RFC1884], such that all components of the address are indicated and leading zeros are omitted. This provides a consistent means of resolving ipHosts by address."
[RFC1884]のセクション2.2.1で定義されるように、好ましい 『フォーム「のIPv6アドレスを持つホストは、その中に書かれなければならない』アドレスのすべてのコンポーネントが示され、先行ゼロが省略されている。これによりipHostsを解決する一貫した手段を提供するように住所。"
However, the defined format mentioned above has been replaced, hence it is no longer valid.
しかし、上記の定義されたフォーマットが交換された、したがってそれはもはや有効ではありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.43. : URI Resolution Services Necessary for URN Resolution
6.43. ：URN解決のために必要なURI解決サービス
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.45. : Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol
6.45. ：インターネット印刷プロトコルのためのモデルの構造のための理論的根拠とプロトコル
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.47. : An LDAP Control and Schema for Holding Operation Signatures
6.47. ：保持動作署名のためのLDAP制御とスキーマ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.48. : A Tagged Index Object for use in the Common Indexing Protocol
6.48. ：一般的なインデックスプロトコルで使用するために、タグ付きインデックスオブジェクト
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This specification claims to be both IPv4 and IPv6 aware, but in Section 2.8. (An HTCP/0.0 AUTH has the following structure), it makes the following statement:
この仕様は、IPv4とIPv6の両方を知っておくと主張するが、セクション2.8インチ（HTCP / 0.0 AUTHは、以下の構造を有している）、それは次のステートメントを作ります：
"SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 digest (see [RFC 2104]), with a B value of 64, of the following elements, each of which is digested in its "on the wire" format, including transmitted padding if any is covered by a field's associated LENGTH:
含む、ワイヤ上の 『形式「署名はHMAC-MD5ダイジェストは、その中で消化されてそれぞれが次の要素の64のB値と、（[RFC 2104]を参照）を保持COUNTSTR [3.1]です』いずれかのフィールドの関連する長さでカバーされている場合、パディングを送信：
IP SRC ADDR [4 octets]
IP SRC PORT [2 octets]
IP DST ADDR [4 octets]
IP DST PORT [2 octets]
HTCP MAJOR version number [1 octet]
HTCP MINOR version number [1 octet]
SIG-TIME [4 octets]
SIG-EXPIRE [4 octets]
HTCP DATA [variable]
KEY-NAME (the whole COUNTSTR [3.1]) [variable]"
The given SIGNATURE calculation should be expanded to support IPv6 16 byte addresses.
与えられたSIGNATURE計算は、IPv6の16バイトのアドレスをサポートするように拡張されなければなりません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This protocol is both IPv4 and IPv6 aware and needs no changes.
このプロトコルは、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
In section 3.4 (Address Formats), there are explicit references to IPv4 addressing:
3.4節（アドレス形式）では、IPv4アドレスへの明示的な参照があります。
"The following address format numbers are definite for nodes, immediately connected to the global IPv4 network:
「次のアドレス形式番号は直ちにグローバルIPv4ネットワークに接続され、ノードのための明確です。
N 4-0-0 (4) N 4-0-1 (4-1) N 4-0-2 (4-2)
N 4-0-0（4）N 4-0-1（4-1）N 4-0-2（4-2）
The appropriate formats of 128-bit addresses:
128ビットのアドレスの適切なフォーマット
Octets:
+0 +1 +2 +3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 1| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|1 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Free
自由
It is not used by the protocol.
これは、プロトコルによって使用されていません。
IP address
IPアドレス
It sets the node address in the global IPv4 network."
これは、グローバルなIPv4ネットワーク内のノードアドレスを設定します。」
This section needs to be re-written, so that the specification becomes IPv6 compliant.
仕様は、IPv6対応になるように、このセクションでは、再書き込みする必要があります。
This protocol is both IPv4 and IPv6 aware, and thus requires no changes.
このプロトコルは、IPv4とIPv6の両方が認識しているため、変更する必要はありません。
6.57. : OpenLDAP Root Service An experimental LDAP referral service
6.57. ：OpenLDAPのルートサービスの実験的LDAPの紹介サービス
Section 5. (Using the Service) states:
（サービスの使用）第5節は述べています：
"The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over TCP/IPv4. Future incarnations of this service may support TCP/IPv6 or other transport/internet protocols."
「サービスは、TCP / IPv4のオーバーのLDAPv3とのLDAPv2 + [のLDAPv2 +]クライアントをサポートしています。このサービスの今後の化身は、TCP / IPv6のまたは他の輸送/インターネット・プロトコルをサポートすることができます。」
This survey contemplates 257 RFCs, having 34 (12.84%) been identified as having some form of IPv4 dependency. Results are broken down as follows:
この調査は、IPv4依存の何らかの形態を有するものとして同定されて34（12.84パーセント）を有する257のRFCを、意図します。次のように結果が分類されます。
Standards: 1 out of 20 or 5.00%
Draft Standards: 4 out of 25 or 16.00%
Proposed Standards: 19 out of 155 or 12.26%
Experimental RFCs: 10 out of 57 or 17.54%
Of the 33 identified, the majority simply require minor actions, such as adding a caveat to IPv6 addressing that would avoid ambiguity, or re-writing a section to avoid IP-version dependent syntax. The remaining instances are documented below. The authors have attempted to organize the results in a format that allows easy referencing by other protocol designers.
識別33のうち、大半は単純に、このようなことに対処IPv6への警告を追加するなど、マイナーアクションは、曖昧さを回避する必要、またはIP-バージョン依存の構文を避けるために再書き込みセクション。残りのインスタンスは、以下の文書化されています。著者は、他のプロトコルデザイナーが簡単に参照することができます形式で結果を整理しようとしてきました。
Problems have already been fixed in [5].
問題はすでに[5]に固定されています。
7.2.1. : Network Time Protocol (version 3): Specification, Implementation and Analysis
7.2.1. ：ネットワークタイムプロトコル（バージョン3）：仕様、実装と分析
As documented in Section 4.4. above, there are too many specific references to the use of 32-bit IPv4 addresses. An updated specification to support NTP over IPv6 is needed. However, there has been some work related with this issue, as an already expired work in progress, allegedly documents. Also, there is at least one IPv6 NTP implementation.
4.4節に記述されているように。上記のように、32ビットのIPv4アドレスの使用に非常に多くの特定の参考文献が存在します。 IPv6の上でNTPをサポートするように更新仕様が必要とされています。しかし、進行中のすでに期限切れの仕事、容疑者の文書として、この問題に関連したいくつかの作業がありました。また、少なくとも1つのIPv6 NTPの実装があります。
URI's allow the literal use of IPv4 addresses but have no specific recommendations on how to represent literal IPv6 addresses. This problem has already been addressed in [3].
URIのは、IPv4アドレスの文字通りの使用を許可しますが、リテラルIPv6アドレスを表現する方法についての具体的な提言を持っていません。この問題は、すでに[3]で解決されています。
HTTP allows the literal use of IPv4 addresses, but has no specific recommendations on how to represent literal IPv6 addresses. This problem has already been addressed in [3].
HTTPは、IPv4アドレスのリテラルを使用できますが、リテラルIPv6アドレスを表現する方法についての具体的な提言を持っていません。この問題は、すでに[3]で解決されています。
There is a dependency in the definition of the TTYLOC Number which would require an updated version of the protocol. However, since this functionality is of marginal value today, an updated version might not make sense.
プロトコルの更新バージョンを必要とするTTYLOC数の定義における依存性があります。この機能は、限界値の今日であるので、更新されたバージョンでは意味を成さない場合があります。
URL's with IPv4 dependencies have already been addressed in [3].
IPv4の依存関係を持つURLのは、すでに[3]で対処されています。
Note that these dependencies affect other specifications as well, such as RFC 2122, RFC 2192, RFC 2193, RFC 2255, RFC 2371, and RFC 2384. All of these protocols have to revisited, and are not described separately in this memo.
これらの依存関係は、RFC 2122、RFC 2192、RFC 2193、RFC 2255、RFC 2371、およびRFC 2384これらのプロトコルのすべてとして、同様に他の仕様に影響を与える再訪する必要があり、このメモで個別に説明されていないことに注意してください。
The problems of this specification have already been addressed in [4].
この仕様の問題は、すでに[4]で対処されています。
POP URL IPv4 dependencies have already been addressed in [3].
POPのURLのIPv4の依存関係は、すでに[3]で対処されています。
The problems of this specification have already been addressed in [4].
この仕様の問題は、すでに[4]で対処されています。
Some textual updates and clarifications to MX processing would likely be useful. The operational scenarios and guidelines to avoid the problems have been described in [6].
MX処理するためにいくつかのテキストの更新と説明は、おそらく有用であろう。問題を回避するための動作シナリオとガイドラインは、[6]に記載されています。
Extensions should be defined to support IPv6 addresses.
拡張機能は、IPv6アドレスをサポートするために定義する必要があります。
The packet format of this protocol depends on IPv4, and would require updating to add IPv6 support. However, the protocol is not believed to be in use, so such an update may not be warranted.
このプロトコルのパケットフォーマットは、IPv4に依存し、IPv6のサポートを追加するアップデートが必要となります。しかし、プロトコルが使用中ではないと考えられるので、そのような更新が保証されなくてもよいです。
This specification only requires a text update to become IPv6 compliant.
この仕様は、IPv6のみの対応になるために、テキストの更新が必要です。
This specification only requires a text update to become IPv6 compliant.
この仕様は、IPv6のみの対応になるために、テキストの更新が必要です。
This protocol relies on IPv4 IGMP Multicast. To become IPv6 compliant, a new version should be produced.
このプロトコルはIPv4のIGMPマルチキャストに依存しています。 IPv6対応になるためには、新しいバージョンが作成されなければなりません。
This document tries to provide IPv6 support but it relies on an outdated format for IPv6 addresses. Thus, there is the need for an IPv6 compliant version.
この文書は、IPv6のサポートを提供しようとしますが、それはIPv6アドレスの時代遅れの形式に依存しています。このように、IPv6対応バージョンの必要性があります。
Phil would like to acknowledge the support of the Internet Society in the research and production of this document. Additionally, Phil would like to thank his partner in all ways, Wendy M. Nesser.
フィルは、この文書の研究と生産におけるインターネット協会の支援を承認したいと思います。さらに、フィルはすべての方法で彼のパートナー、ウェンディM. Nesserに感謝したいと思います。
This document provides an exhaustive documentation of current IETF documented standards IPv4 address dependencies. Such process does not have security implications in itself.
この文書では、現在IETF文書の標準IPv4アドレスの依存関係の徹底的なドキュメントを提供しています。このようなプロセスは、それ自体がセキュリティ上の意味合いを持っていません。
[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.ベルイストローム、エディタを、RFC 3789、2004年6月 "のIPv4の調査の概要は、現在展開IETF標準のアドレス"。
[2] Bradner, S., "The Internet Standards Process - version 3", BCP 9, RFC 2026, October 1996.
[2]ブラドナー、S.、 "インターネット標準化過程 - バージョン3"、BCP 9、RFC 2026、1996年10月。
[3] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[3] HindenとR.、大工、B.およびL. Masinterを、 "リテラルIPv6アドレスのフォーマットURLの中に"、RFC 2732、1999年12月。
[4] Guttman, E., "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001.
[4]グットマン、E.、 "IPv6のサービスロケーションプロトコルの変更"、RFC 3111、2001年5月。
[5] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998.
[5]オールマン、M.、Ostermann、S.とC.メッツ、 "IPv6とNATsのためのFTP拡張機能"、RFC 2428、1998年9月。
[6] Hagino, J. and M. Nakamura, "SMTP operational experience in mixed IPv4/IPv6 environements", Work in Progress.
[6]萩野、J.とM.中村、 "IPv4 / IPv6混在environementsにおけるSMTP運用経験"、ProgressのWork。
Rute Sofia FCCN Av. Brasil, 101 1700 Lisboa, Portugal
ルーテソフィアFCCNのAv。ブラジル、101 1700リスボン、ポルトガル
Phone: +351 91 2507372 EMail: rsofia@zmail.pt
電話番号：+351 91 2507372 Eメール：rsofia@zmail.pt
Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034
フィリップJ. Nesser II校長Nesser＆Nesserコンサルティング13501第百アヴェNE、＃5202カークランド、WA 98034
Phone: +1 425 481 4303 Fax: +1 425 482 9721 EMail: phil@nesser.com
電話：+1 425 481 4303ファックス：+1 425 482 9721 Eメール：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。