[要約] RFC 3795は、IETFのアプリケーション領域の標準トラックおよび実験的なドキュメントで使用されているIPv4アドレスの調査に関するものです。その目的は、現在のIETFドキュメントで使用されているIPv4アドレスの使用状況を把握することです。
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
現在展開されているIETFアプリケーションエリア標準の追跡および実験文書におけるIPv4アドレスの調査
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This 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を二重にサポートするために、または少なくとも再実装することです。この遷移にはいくつかの暫定ステップが必要です。そのうちの1つは、使用される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.
そのステップを達成するには、実験的なRFCと同様に、現在の標準（フル、ドラフト、提案）が経験したすべてのIPv4依存関係を調査および文書化する必要があります。したがって、このドキュメントでは、IETFアプリケーションエリアが展開された標準が発生する可能性のある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。各セクションについて、標準はRFC数、つまりRFC 1からRFC 3200までのRFC番号によって分析されます。これの例外は、RFC 3200を超えるRFCです。3200。また、各RFCについて提示されたコメントは本質的にRAWです。つまり、各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."
「ポートコマンドは、ポートH1、H2、H3、H4、P1、P2であり、H1はインターネットホストアドレスの高次8ビットです。」
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依存関係はありません。
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標準トラックプロセスの最後から2番目の成熟度レベルにある仕様に与えられる命名法です。それらは最終仕様と見なされます。これは、見つかった特定の問題を解決するために変更のみを経験する可能性があります。仕様は、少なくとも2つの既知の独立した相互運用可能な実装がある場合にのみ、ドラフト標準と見なされます。したがって、ドラフト基準は通常非常に成熟しており、広く使用されています。
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.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）はエントリのモードと一致します。アクセスは許可されます。マスクの適切な選択を通じて、モードごとのリクエストを個々のアドレス、特定のサブネットまたはネットアドレスに制限することができます。または、まったく制限がありません。アクセスコントロールリストは、ピアが関連性を作成できるフィルターとして機能します。「
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."
「SET TRAPアドレス/ポート（6）：コマンドアソシエーション識別子、ステータス、データフィールドは無視されます。後続のトラップメッセージのアドレスとポート番号は、コントロールメッセージ自体のソースアドレスとポートから取得されます。トラップ応答メッセージはコマンドのシーケンスフィールドから取得されます。応答関連識別子、ステータス、およびデータフィールドは重要ではありません。実装には、監視プログラムが長い間隔の後にこの情報を更新しない場合、トラップ送信を防ぐ正気のタイムアウトを含める必要があります。」
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依存関係はありません。
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 "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)."
「Foobar」という名前のファイル、Octet（バイナリ）転送モードの読み取り要求であり、ブロックサイズは1428オクター（イーサネット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依存関係はありません。
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."
「ホストは、ネットワークホストのドメイン名、またはそのIPv4アドレスは、 "。"で区切られた4つの10進数桁グループのセットとしてです。文字通りの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 ]]
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接続をリスニングするサーバーに配置され、リソースのリクエストURIはABS_PATH（セクション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アドレスをサポートするかどうかは不明です。実際、IPv6アドレスで「：」セパレーターを使用すると、URIを解析すると誤解が発生します。独自の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依存関係はありません。
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依存関係はありません。
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依存関係はありません。
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."
「TTYLOC番号は、2つの32ビット番号で構成される64ビット番号です。32ビットの公式ARPAインターネットホストアドレス（マルチホームホストのアドレスのいずれか）と32ビット番号指定されたホストの端子を表します。[0.0.0.0]のホストアドレスは「不明」と定義され、fffffffffの端子数（小数点以下）の端子数は「不明」と定義され、端子は定義されています。ffffffffeの数（ヘックス、または小数で-2）は、端子に接続されていないプロセスに対して「分離」されると定義されています。
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依存関係はありません。
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依存関係はありません。
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間の相互作用のゲートウェイを定義しているため、セクション3.16で、上記で既に調査されているFTPに関連付けられている唯一の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 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."
「ホストネットワークホストの完全資格のドメイン名、またはそのIPアドレスは、「 "。」で区切られた4つの10進数桁グループのセットとして。完全に適格なドメイン名は、RFC 1034 [13]およびセクションのセクション3.5で説明されています。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スキームパート：
ip-schemepart = "//" login [ "/" urlpath ]
ip-schemepart = "//" login ["/" urlpath]
login = [ user [ ":" password ] "@" ] hostport
hostport = host [ ":" port ]
host = hostname | hostnumber"
Again, this also has implications in terms of IP-version neutrality.
繰り返しますが、これはIPバージョンの中立性の観点からも影響を及ぼします。
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
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"
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依存関係を提示しませんが、実装を変更して、IPバージョンが元のリクエストで使用されているIPバージョンを確認するために変更する必要があるため、IPv6アドレスを返すかどうかを判断できます。
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."
Services ServerのディレクトリのIPアドレスは、1〜2日間変更されず、他の情報も変更されない場合があります。」
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アドレス、ポートナンバーです。その情報は、数週間発生した可能性のある最後の世論調査以来サーバーでキャッシュされています。したがって、そのような接続が失敗した場合、クライアントは代わりにサーバーハンドルを使用するためにフォールバックする必要があります。つまり、サービスサーバーのディレクトリとそのサーバーハンドルのサーバーのクエリに連絡します。これを行うことにより、クライアントは常に取得する必要があります。最後の既知のホスト名。
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"
The paragraph does not contain IPv4 specific syntax. Hence, IPv6 compliance will be implementation dependent.
段落には、IPv4固有の構文は含まれていません。したがって、IPv6コンプライアンスは実装に依存します。
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 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>
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の。<port>が省略されている場合、ポートは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.
IPv4依存関係は、RFC 1738で定義されているように、IPv4アドレスを含む<ホスト>部分の可能性に関連している場合があります（上記のセクション5.31を参照）。RFC 1738のコンテキストで問題が解決すると、この問題は自動的に解決されます。
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 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。また、セクション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-spec>の間にコンマデリミタが必要です。点線の小数のIPアドレス表記の使用は、ドメイン名サービスのない環境でのみ使用する必要があります。」
Later, in Section 20.4. (Address Specification in Service Location) there is also the following reference to addr-spec:
後で、セクション20.4で。（サービス場所のアドレス仕様）AddR-Specへの次の参照もあります。
"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とDASは、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.
マルチキャストとブロードキャストすべてのサービスロケーションエンティティは、デフォルトでマルチキャストを使用する必要があります。ブロードキャストメッセージを使用する機能は、UASおよびSASに対して構成可能でなければなりません。ブロードキャストメッセージは、すべてのサービスロケーションエンティティがマルチキャストをサポートするハードウェアまたはソフトウェアを持っているわけではない環境で使用されます。
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."
マルチキャストRADIUSマルチキャストリクエストは、サイト内のすべてのサブネットに送信する必要があります。サイトのデフォルトのマルチキャスト半径は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
サービスロケーション一般マルチキャストアドレス：224.0.1.22ディレクトリエージェントディスカバリーマルチキャストアドレス：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依存関係はありません。
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.
仕様にはIPv4依存関係があります。これは、ドキュメントに不可欠なRFC 1738はIPv6認識ではないためです。
Section 6. (Formal Syntax) presents the following statement:
セクション6.（正式な構文）は、次のステートメントを示します。
"referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"; See
[RFC-1738] for <url> definition"
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です。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the following example:
セクション4.1。（紹介をログインして認証）次の例を示します。
"Example: C: A001 LOGIN MIKE PASSWORD
S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified
user is invalid on this server. Try 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.
構文「user@server2」は頻繁に表示されますが、「server2」の形式に関連する仕様はありません。したがって、ホスト名の許容値を決定するのは個々の実装次第です。これには、明示的なIPv6アドレスが含まれている場合と含まれない場合があります。
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 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.
仕様にはIPv4依存関係があります。これは、ドキュメントに不可欠なRFC 1738はIPv6認識ではないためです。
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依存関係はありません。
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が特定のデータをキャッシュ内のデータに関連付けるバイト文字列。たとえば、オリジネーターは、特定の4バイト文字列をATMアドレスのIPアドレスのバインディングに割り当てることができます。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依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
In section 7. (TIP Transaction Manager Identification and Connection Establishment):
セクション7で（チップトランザクションマネージャーの識別と接続確立）：
"The <hostport> component comprises:
「<hostport>コンポーネントは次のとおりです。
<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.
ここで、<host>はa <dns name>またはan <ip address>のいずれかです。<port>は、トランザクションマネージャー（またはプロキシ）がチップ接続を確立するためのリクエストを聞いているポートを指定する10進番号です。ポート番号が省略されている場合、標準のチップポート番号（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.
A <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の後半（ヒントユニフォームリソースロケーター）：
"A TIP URL takes the form:
「チップURLが形式を取得します。
tip://<transaction manager address>?<transaction 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):
ここで、<トランザクションマネージャーアドレス> TIPトランザクションマネージャーを識別します（上記のセクション7で定義されています）。<トランザクション文字列>トランザクション識別子を指定します。これは、2つのフォーム（標準または非標準）のいずれかをとる場合があります。
i. "urn:" <NID> ":" <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で指定されているように、標準的なトランザクション識別子。ここで、<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
Note that Namespace Ids require registration. See [7] for details on how to do this."
名前空間IDには登録が必要であることに注意してください。これを行う方法の詳細については、[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:
「ポップURLは一般的な形式です。
pop://<user>;auth=<auth>@<host>:<port>
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 (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 2384は、RFC 1738が適切に更新される場合にのみIPv6に準拠します。
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.93. RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration
5.93. RFC 2422：通行料の音声-32 kbit/s 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拡張機能を文書化するため、現在の議論のコンテキストでは考慮されていません。
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
値タイプ：テキスト
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-Specの同一の構文であることをお勧めします。一意性を保証する良い方法は、「@」の右側に識別子が作成されたホストのドメイン名またはドメインリテラル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. RFC 2446: iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries
5.100。RFC 2446：ICALENENDARトランスポートに依存しない相互運用性プロトコル（ITIP）スケジューリングイベント、忙しい時間、TO-DOS、Journalエントリ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.101. RFC 2447: iCalendar Message-Based Interoperability Protocol (iMIP)
5.101。RFC 2447：ICALENDARメッセージベースの相互運用性プロトコル（IMIP）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.102. RFC 2449: POP3 Extension Mechanism
5.102。RFC 2449：POP3拡張メカニズム
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.103. RFC 2476: Message Submission
5.103。RFC 2476：メッセージの送信
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に制限するものではありません。
5.104. RFC 2480: Gateways and MIME Security Multiparts
5.104。RFC 2480：ゲートウェイとマイムセキュリティマルチパート
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.105. RFC 2518: HTTP Extensions for Distributed Authoring
5.105。RFC 2518：分散オーサリング用のHTTP拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.106. RFC 2530: Indicating Supported Media Features Using Extensions to DSN and MDN
5.106。RFC 2530：DSNとMDNへの拡張機能を使用したサポートされているメディア機能を示す
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.107. RFC 2532: Extended Facsimile Using Internet Mail
5.107。RFC 2532：インターネットメールを使用してファクシミリを拡張します
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.108. RFC 2533: A Syntax for Describing Media Feature Sets
5.108。RFC 2533：メディア機能セットを説明するための構文
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.109. RFC 2534: Media Features for Display, Print, and Fax
5.109。RFC 2534：ディスプレイ、印刷、ファックスのメディア機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.110. RFC 2554: SMTP Service Extension for Authentication
5.110。RFC 2554：認証用SMTPサービス拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.111. RFC 2557: MIME Encapsulation of Aggregate Documents, such as HTML
5.111。RFC 2557：HTMLなどの集計ドキュメントのMIMEカプセル化
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.112. RFC 2589: Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
5.112。RFC 2589：Lightweight Directory Access Protocol（V3）：動的ディレクトリサービスの拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.113. RFC 2595: Using TLS with IMAP, POP3 and ACAP
5.113。RFC 2595：IMAP、POP3、ACAPでTLSを使用する
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.114. RFC 2596: Use of Language Codes in LDAP
5.114。RFC 2596：LDAPでの言語コードの使用
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.115. RFC 2608: Service Location Protocol, Version 2
5.115。RFC 2608：サービスロケーションプロトコル、バージョン2
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>は、以前のレスポンダーリストです。この<string-list>には、点線の小数表記IP（V4）アドレスが含まれており、すべての可能な結果を得るために繰り返しマルチキャストです（セクション6.3を参照）。UASはこの発見アルゴリズムを実装する必要があります。SASは、他の手段によって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."
「SAは、<Prlist>のSAのアドレスを含むすべてのリクエストを静かにドロップします。複数のネットワークインターフェイスを備えたSAは、<prlist>のエントリのいずれかがそのインターフェイスのいずれかに等しいかどうかを確認する必要があります。IPv4の小数点以下のアドレスに準拠していないことは無視されます。<prlist>の残りは正常に処理され、エラーは返されません。」
To become IPv6 compliant, this protocol requires a new version.
IPv6に準拠するためには、このプロトコルには新しいバージョンが必要です。
5.116. RFC 2609: Service Templates and Service: Schemes
5.116。RFC 2609：サービステンプレートとサービス：スキーム
Section 2.1. (Service URL Syntax) defines:
セクション2.1。（Service URL Syntax）は次のことを定義します。
"The ABNF for a service: URL is:
「サービスのABNF：URLは次のとおりです。
hostnumber = ipv4-number
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)"
This document presents many other references to hostnumber, which requires an update to support IPv6.
このドキュメントでは、IPv6をサポートするための更新が必要なHostNumberへの他の多くの参照を示しています。
5.117. RFC 2640: Internationalization of the File Transfer Protocol
5.117。RFC 2640：ファイル転送プロトコルの国際化
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.118. RFC 2645: ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses
5.118。RFC 2645：ダイナミックIPアドレスを備えたオンデマンドメールリレー（ODMR）SMTP
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.119. RFC 2646: The Text/Plain Format Parameter
5.119。RFC 2646：テキスト/プレーンフォーマットパラメーター
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.120. RFC 2651: The Architecture of the Common Indexing Protocol (CIP)
5.120。RFC 2651：共通インデックスプロトコル（CIP）のアーキテクチャ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.121. RFC 2652: MIME Object Definitions for the Common Indexing Protocol
5.121。RFC 2652：一般的なインデックス作成プロトコルのMIMEオブジェクト定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.122. RFC 2653: CIP Transport Protocols
5.122。RFC 2653：CIP輸送プロトコル
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.123. RFC 2732: Format for Literal IPv6 Addresses in URL's
5.123。RFC 2732：URLのリテラルIPv6アドレスのフォーマット
This document defines an IPv6 specific protocol and hence, it is not discussed in this document.
このドキュメントはIPv6固有のプロトコルを定義するため、このドキュメントでは説明されていません。
5.124. RFC 2738: Corrections to "A Syntax for Describing Media Feature Sets"
5.124。RFC 2738：「メディア機能セットを説明するための構文」への修正
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.125. RFC 2739: Calendar Attributes for vCard and LDAP
5.125。RFC 2739：VCARDおよびLDAPのカレンダー属性
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.126. RFC 2806: URLs for Telephone Calls
5.126。RFC 2806：電話用のURL
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.127. RFC 2821: Simple Mail Transfer Protocol
5.127。RFC 2821：単純なメール転送プロトコル
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レコード処理は、いくつかの種類の障害モードを引き起こす可能性があります。
5.128. RFC 2822: Internet Message Format
5.128。RFC 2822：インターネットメッセージ形式
Section 3.4.1 (Addr-spec specification) contains:
セクション3.4.1（addr-spec仕様）には以下が含まれます。
"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. RFC 2846: GSTN Address Element Extensions in E-mail Services
5.129。RFC 2846：GSTNアドレスは、電子メールサービスの要素拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.130. RFC 2849: The LDAP Data Interchange Format (LDIF) - Technical Specification
5.130。RFC 2849：LDAPデータインターチェンジ形式（LDIF） - 技術仕様
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.131. RFC 2852: Deliver By SMTP Service Extension
5.131。RFC 2852：SMTPサービスエクステンションによる配信
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.132. RFC 2879: Content Feature Schema for Internet Fax (V2)
5.132。RFC 2879：インターネットファックス用のコンテンツ機能スキーマ（V2）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.133. RFC 2891: LDAP Control Extension for Server Side Sorting of Search Results
5.133。RFC 2891：サーバー側の検索結果のソートのためのLDAP制御拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.134. RFC 2910: Internet Printing Protocol/1.1: Encoding and Transport
5.134。RFC 2910：インターネット印刷プロトコル/1.1：エンコーディングとトランスポート
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.135. RFC 2911: Internet Printing Protocol/1.1: Model and Semantics
5.135。RFC 2911：インターネット印刷プロトコル/1.1：モデルとセマンティクス
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.136. RFC 2912: Indicating Media Features for MIME Content
5.136。RFC 2912：MIMEコンテンツのメディア機能を示す
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.137. RFC 2913: MIME Content Types in Media Feature Expressions
5.137。RFC 2913：メディア機能表現のMIMEコンテンツタイプ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.138. RFC 2919: List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
5.138。RFC 2919：List-ID：メーリングリストの識別用の構造化されたフィールドと名前空間
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.139. RFC 2938: Identifying Composite Media Features
5.139。RFC 2938：複合メディア機能の識別
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.140. RFC 2965: HTTP State Management Mechanism
5.140。RFC 2965：HTTP状態管理メカニズム
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依存関係の可能性について疑いの余地がないように、追加する必要があります。
5.141. RFC 2971: IMAP4 ID extension
5.141。RFC 2971：IMAP4 ID拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.142. RFC 2987: Registration of Charset and Languages Media Features Tags
5.142。RFC 2987：CharsetおよびLanguages Media機能の登録タグ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.143. RFC 3009: Registration of parityfec MIME types
5.143。RFC 3009：ParityFec Mimeタイプの登録
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.144. RFC 3017: XML DTD for Roaming Access Phone Book
5.144。RFC 3017：ローミングアクセス電話帳のXMLDTD
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>"
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>"
It should be straightforward to implement elements that are IPv6 aware.
IPv6認識の要素を実装するのは簡単です。
5.145. RFC 3023: XML Media Types
5.145。RFC 3023：XMLメディアタイプ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.146. RFC 3028: Sieve: A Mail Filtering Language
5.146。RFC 3028：ふるい：メールフィルタリング言語
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.147. RFC 3030: SMTP Service Extensions for Transmission of Large and Binary MIME Messages
5.147。RFC 3030：大型およびバイナリMIMEメッセージを送信するためのSMTPサービス拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.148. RFC 3049: TN3270E Service Location and Session Balancing
5.148。RFC 3049：TN3270Eサービスの場所とセッションバランス
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.149. RFC 3059: Attribute List Extension for the Service Location Protocol
5.149。RFC 3059：サービスロケーションプロトコルの属性リスト拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.150. RFC 3080: The Blocks Extensible Exchange Protocol Core (BEEP)
5.150。RFC 3080：ブロック拡張可能な交換プロトコルコア（ビープ音）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.151. RFC 3081: Mapping the BEEP Core onto TCP
5.151。RFC 3081：ビープコアをTCPにマッピングします
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.152. RFC 3111: Service Location Protocol Modifications for IPv6
5.152。RFC 3111：IPv6のサービスロケーションプロトコル変更
This is an IPv6 related document and is not discussed in this document.
これはIPv6関連のドキュメントであり、このドキュメントでは説明されていません。
5.153. RFC 3302: Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
5.153。RFC 3302：タグイメージファイル形式（TIFF） - 画像/TIFF MIMEサブタイプの登録
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.154. RFC 3404: Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application
5.154。RFC 3404：ダイナミック委任ディスカバリーシステム（DDDS）パート4：ユニフォームリソース識別子（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への明示的な依存関係はありません。ただし、RFC 2396で指定されたURI形式を参照する場合（セクション4.3。最初の段落を参照）、RFC 2732への参照も追加する必要があります。
5.155. RFC 3501: Internet Message Access Protocol - Version 4rev1
5.155。RFC 3501：インターネットメッセージアクセスプロトコル -バージョン4REV1
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.
「<who-any-provides？>リソース）およびそれが考えている他のホストの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."
<dos-Anyone-Provide？>このメッセージは、上記の「サードパーティ」バリアントと再び<do-you-provide？>メッセージに似ています。前と同様に、確認ホストは、独自のIPアドレスと、指定されたリソースを提供する可能性があると考えている他のホストのIPアドレスを返す必要があり、にリストされているのと同じIPアドレスをReply Resource仕様に返すことを禁止されています。リクエストリソース仕様。<do-you-provide？>ケースのように、同じ理由で、このメッセージも放送されない可能性があります。」
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
+--------+--------+--------+--------+---//---+
| | |
|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-address-list>（<ip-address-list>フィールドに含まれるIPアドレスの数は、リソース仕様の最後の4*<iplengt>オクテットを占有します）。リクエストメッセージでは、これは対応する返信リソース仕様に含まれる可能性のある適格アドレスの最大数です。特に有用ではありませんが、0である可能性があり、その場合、返された仕様にIPアドレスを使用してリソース名を修飾するためのスペースを提供しません。返信メッセージでは、これはリソースを提供することが知られている適格アドレスの数です。対応するリクエスト仕様で指定された数を超えない場合があります。このフィールドは、リクエストメッセージに0として提供されていない場合を除き、返信メッセージでは0ではない場合があり、確認ホストはスペースが提供されていれば1つ以上のIPアドレスを返します。
<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-Address-List>は、それらの特定のアドレスに関してリソース仕様を適格にするために使用される4オクタートIPアドレスのリストです。返信メッセージでは、これらは確認ホストのIPアドレス（必要に応じて）およびそのリソースを提供することが知られている他のホストのアドレス（リストの長さの制限の対象）です。リクエストメッセージでは、これらはリソース情報が返されないホストのIPアドレスです。このようなメッセージでは、これらのアドレスは通常、応答メッセージの検討から提供されたアドレスを具体的に除外することを目的としていない限り、いくつかの「無害な」値（クエリホストのアドレスなど）に初期化する必要があります。」
This section requires re-writing considering the 128-bit length of IPv6 addresses, and will clearly impact implementations.
このセクションでは、128ビットのIPv6アドレスを考慮して書き直す必要があり、実装に明らかに影響を与えます。
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 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依存関係はありません。
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):
特定のIPv4アドレス指定参照は2つしかありません。最初はセクション6.2に示されています。（コマンド応答）：
"203 RPL_TRACEUNKNOWN
"???? <class> [<client IP address in dot form>]""
The second appears in Section 8.12 (Configuration File):
2番目はセクション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. RFC 1465: Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing
6.14. RFC 1465：マルチプロトコル /マルチネットワーク環境テーブル形式の静的ルーティングのためのX.400 MHSサービスのルーティング調整
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 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依存関係はありません。
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依存関係はありません。
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依存関係はありません。
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 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名「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名前「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名「Ipnetmasknumber 'desc' ip netmaskは点線の小数として、例：例：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."
「IPv6アドレスを持つホストは、[RFC1884]のセクション2.2.1で定義されている「優先」フォームで記述する必要があります。そのため、アドレスのすべてのコンポーネントが示され、主要なゼロが省略されます。住所。"
However, the defined format mentioned above has been replaced, hence it is no longer valid.
ただし、上記の定義された形式は置き換えられているため、もはや有効ではありません。
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依存関係はありません。
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:
「署名は、次の要素のうち64のB値を持つHMAC-MD5ダイジェスト（[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.
指定された署名計算を拡張して、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の両方であるため、変更は必要ありません。
Section 5. (Using the Service) states:
セクション5.（サービスを使用）stape：
"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:
この調査では、34（12.84％）が何らかの形のIPv4依存関係を持っていると特定された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%
標準：20または5.00％のドラフト標準のうち1つの基準：25または16.00％のうち4つの提案された基準：155または12.26％の実験RFCS：57または17.54％のうち10
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-version依存の構文を避けるためにセクションを書き直すなど、単に軽微なアクションを必要とします。残りのインスタンスは以下に文書化されています。著者は、他のプロトコル設計者による簡単な参照を可能にする形式で結果を整理しようとしました。
Problems have already been fixed in [5].
問題はすでに[5]で修正されています。
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・ネッサーに感謝したいと思います。
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. Bergstrom、編集者、「現在展開されているIETF標準におけるIPv4アドレスの調査の紹介」、RFC 3789、2004年6月。
[2] Bradner, S., "The Internet Standards Process - version 3", BCP 9, RFC 2026, October 1996.
[2] Bradner、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.、Carpenter、B。and L. Masinter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。
[4] Guttman, E., "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001.
[4] Guttman、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] Allman、M.、Ostermann、S。、およびC. Metz、「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] Hagino、J。およびM. Nakamura、「混合IPv4/IPv6環境におけるSMTP運用体験」、進行中の作業。
Rute Sofia FCCN Av. Brasil, 101 1700 Lisboa, Portugal
rute sofia fccn av。ブラジル、101 1700リスボア、ポルトガル
Phone: +351 91 2507372
EMail: rsofia@zmail.pt
Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034
フィリップJ.ネッサーIIプリンシパルネッサー＆ネッサーコンサルティング13501 100th Ave NE、＃5202 Kirkland、WA 98034
Phone: +1 425 481 4303
Fax: +1 425 482 9721
EMail: phil@nesser.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。