[要約] RFC 3794は、IETFのトランスポートエリアの標準トラックおよび実験的なドキュメントで使用されているIPv4アドレスの調査に関するものです。このRFCの目的は、現在のIETFドキュメントで使用されているIPv4アドレスの使用状況を把握することです。
Network Working Group P. Nesser, II
Request for Comments: 3794 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Survey of IPv4 Addresses in Currently Deployed IETF Transport 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 seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
このドキュメントでは、現在展開されているIETF輸送エリアの文書化された標準におけるIPv4アドレスのすべての使用法を文書化しようとしています。すべてのIPv4インターネットからすべてのIPv6インターネットに正常に移行するために、多くの暫定ステップが実行されます。これらの手順の1つは、IPv4依存関係を持つ現在のプロトコルの進化です。これらのプロトコル（およびその実装）がネットワークアドレスが依存しないように再設計されることが期待されていますが、少なくとも二重にIPv4とIPv6をサポートすることに失敗します。この目的のために、実験的なRFCと同様に、すべての標準（フル、ドラフト、提案）が調査され、依存関係が文書化されます。
Table of Contents
目次
1.0. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.0. Document Organization. . . . . . . . . . . . . . . . . . . . 2
3.0. Full Standards . . . . . . . . . . . . . . . . . . . . . . . 2
4.0. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . 10
5.0. Proposed Standards . . . . . . . . . . . . . . . . . . . . . 11
6.0. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . 22
7.0. Summary of Results . . . . . . . . . . . . . . . . . . . . . 27
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . 27
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . 27
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . 29
8.0. Security Considerations. . . . . . . . . . . . . . . . . . . 30
9.0. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
10.0. Normative Reference. . . . . . . . . . . . . . . . . . . . . 30
11.0. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
12.0. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
This document is part of a document set aiming to document all usage of IPv4 addresses in IETF standards. In an effort to have the information in a manageable form, it has been broken into 7 documents conforming to the current IETF areas (Application, Internet, Operations & Management, Routing, Security, Sub-IP and Transport).
このドキュメントは、IETF標準のIPv4アドレスのすべての使用法を文書化することを目的としたドキュメントセットの一部です。情報を管理可能な形式で入手するために、現在のIETF領域（アプリケーション、インターネット、運用と管理、ルーティング、セキュリティ、サブIP、トランスポート）に準拠した7つのドキュメントに分割されています。
For a full introduction, please see the introduction [1].
完全な紹介については、紹介[1]を参照してください。
The rest of the document sections are described below.
ドキュメントの残りのセクションについては、以下に説明します。
Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, and Proposed Standards, and Experimental RFCs. Each RFC is discussed in its turn starting with RFC 1 and ending with (around) RFC 3100. The comments for each RFC are "raw" in nature. That is, each RFC is discussed in a vacuum and problems or issues discussed do not "look ahead" to see if the problems have already been fixed.
セクション3、4、5、および6は、それぞれ、完全、ドラフト、および提案された標準、および実験的RFCの生の分析について説明します。各RFCは、RFC 1から始まり、RFC 3100で終了するターンで説明されています。各RFCのコメントは本質的に「生」です。つまり、各RFCは真空で議論されており、議論された問題や問題は、問題がすでに修正されているかどうかを確認するために「先を見先」ではありません。
Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 6. It is here that all of the results are considered as a whole and the problems that have been resolved in later RFCs are correlated.
セクション7は、セクション3、4、5、および6に示されているデータの分析です。ここでは、すべての結果が全体として考慮され、後のRFCで解決された問題は相関しています。
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
完全なインターネット標準（最も一般的には「標準」と呼ばれる）は、インターネット全体で広く実装および使用されている完全に成熟したプロトコル仕様です。
Although UDP is a transport protocol there is one reference to the UDP/IP interface that states; "The UDP module must be able to determine the source and destination internet addresses and the protocol field from the internet header." This does not force a rewrite of the protocol but will clearly cause changes in implementations.
UDPはトランスポートプロトコルですが、UDP/IPインターフェイスへの参照が1つあります。「UDPモジュールは、インターネットヘッダーからソースおよび宛先インターネットアドレスとプロトコルフィールドを決定できる必要があります。」これにより、プロトコルの書き換えは強制されませんが、実装の変化を明らかに引き起こします。
Section 3.1 which specifies the header format for TCP. The TCP header is free from IPv4 references but there is an inconsistency in the computation of checksums. The text says: "The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length." The first and second 32-bit words are clearly meant to specify 32-bit IPv4 addresses. While no modification of the TCP protocol is necessitated by this problem, an alternate needs to be specified as an update document, or as part of another IPv6 document.
TCPのヘッダー形式を指定するセクション3.1。TCPヘッダーにはIPv4参照がありませんが、チェックサムの計算に矛盾があります。テキストによると、「チェックサムは、TCPヘッダーに概念的に前に付けられた96ビットの擬似ヘッダーもカバーしています。この擬似ヘッダーには、ソースアドレス、宛先アドレス、プロトコル、およびTCP長さが含まれています。」最初と2番目の32ビットの単語は、32ビットIPv4アドレスを指定するための明らかに意図されています。この問題によりTCPプロトコルの変更は必要ありませんが、更新ドキュメントとして、または別のIPv6ドキュメントの一部として指定する必要があります。
This is a layer 3 protocol, and has as such no IPv4 dependencies.
これはレイヤー3プロトコルであり、IPv4の依存関係はありません。
3.4.1. RFC 1001 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS
3.4.1. TCP/UDP輸送に関するNetBiosサービスのRFC1001プロトコル標準：概念と方法
Section 15.4.1. RELEASE BY B NODES defines:
セクション15.4.1。bノードによるリリースは、次の定義を定義します。
A NAME RELEASE DEMAND contains the following information:
名前のリリース要求には、次の情報が含まれています。
- NetBIOS name - The scope of the NetBIOS name - Name type: unique or group - IP address of the releasing node - Transaction ID
- netbios名 - netbios名の範囲 - 名前タイプ：一意またはグループ - リリースノードのIPアドレス - トランザクションID
Section 15.4.2. RELEASE BY P NODES defines:
セクション15.4.2。Pノードによるリリースは、次の定義を示します。
A NAME RELEASE REQUEST contains the following information:
名前のリリースリクエストには、次の情報が含まれています。
- NetBIOS name - The scope of the NetBIOS name - Name type: unique or group - IP address of the releasing node - Transaction ID
- netbios名 - netbios名の範囲 - 名前タイプ：一意またはグループ - リリースノードのIPアドレス - トランザクションID
A NAME RELEASE RESPONSE contains the following information:
名前のリリース応答には、次の情報が含まれています。
- NetBIOS name - The scope of the NetBIOS name - Name type: unique or group - IP address of the releasing node - Transaction ID - Result: - Yes: name was released - No: name was not released, a reason code is provided
- netbios名 - netbios名の範囲 - 名前タイプ：一意またはグループ - リリースノードのIPアドレス - トランザクションID-結果： - はい：名前はリリースされました：名前はリリースされませんでした、理由コードが提供されます
Section 16. NetBIOS SESSION SERVICE states:
セクション16。NetBiosセッションサービスの記述：
The NetBIOS session service begins after one or more IP addresses have been found for the target name. These addresses may have been acquired using the NetBIOS name query transactions or by other means, such as a local name table or cache.
NetBiosセッションサービスは、ターゲット名の1つ以上のIPアドレスが見つかった後に開始されます。これらのアドレスは、NetBios名クエリトランザクションまたはローカル名のテーブルやキャッシュなどの他の手段で取得された可能性があります。
Section 16.1. OVERVIEW OF NetBIOS SESSION SERVICE
セクション16.1。NetBiosセッションサービスの概要
Session service has three phases:
セッションサービスには3つのフェーズがあります。
Session establishment - it is during this phase that the IP address and TCP port of the called name is determined, and a TCP connection is established with the remote party.
セッションの確立 - 呼び出された名前のIPアドレスとTCPポートが決定され、リモートパーティでTCP接続が確立されるのはこのフェーズ中です。
6.1.1. SESSION ESTABLISHMENT PHASE OVERVIEW
6.1.1. セッションの確立フェーズの概要
An end-node begins establishment of a session to another node by somehow acquiring (perhaps using the name query transactions or a local cache) the IP address of the node or nodes purported to own the destination name.
エンドノードは、宛先名を所有することを目的としたノードまたはノードのIPアドレスを取得することにより（おそらく名前クエリトランザクションまたはローカルキャッシュを使用する）、他のノードへのセッションの確立を開始します。
Once the TCP connection is open, the calling node sends session service request packet. This packet contains the following information:
TCP接続が開かれたら、呼び出しノードはセッションサービスリクエストパケットを送信します。このパケットには、次の情報が含まれています。
- Calling IP address (see note) - Calling NetBIOS name - Called IP address (see note) - Called NetBIOS name
- IPアドレスの呼び出し（メモを参照） - netbios名を呼び出す - IPアドレスと呼ばれる（メモを参照） - netbios名と呼ばれる
NOTE: The IP addresses are obtained from the TCP service interface.
注：IPアドレスは、TCPサービスインターフェイスから取得されます。
If a compatible LISTEN exists, and there are adequate resources, then the session server may transform the existing TCP connection into the NetBIOS data session. Alternatively, the session server may redirect, or "retarget" the caller to another TCP port (and IP address).
互換性のあるリスニングが存在し、適切なリソースがある場合、セッションサーバーは既存のTCP接続をNetBIOSデータセッションに変換する場合があります。あるいは、セッションサーバーは、発信者を別のTCPポート（およびIPアドレス）にリダイレクトまたは「リターゲット」する場合があります。
If the caller is redirected, the caller begins the session establishment anew, but using the new IP address and TCP port given in the retarget response. Again a TCP connection is created, and again the calling and called node exchange credentials. The called party may accept the call, reject the call, or make a further redirection.
発信者がリダイレクトされた場合、発信者はセッションの確立を新たに開始しますが、リッジートレンスで与えられた新しいIPアドレスとTCPポートを使用します。繰り返しますが、TCP接続が作成され、再び呼び出しおよび呼び出されたノード交換資格情報が作成されます。呼び出された当事者は、電話を受け入れたり、電話を拒否したり、さらにリダイレクトしたりすることがあります。
17.1. OVERVIEW OF NetBIOS DATAGRAM SERVICE
17.1. NetBiosデータグラムサービスの概要
Every NetBIOS datagram has a named destination and source. To transmit a NetBIOS datagram, the datagram service must perform a name query operation to learn the IP address and the attributes of the destination NetBIOS name. (This information may be cached to avoid the overhead of name query on subsequent NetBIOS datagrams.)
すべてのnetBiosデータグラムには、指定された宛先とソースがあります。NetBiosデータグラムを送信するには、データグラムサービスは、IPアドレスと宛先NetBIOS名の属性を学習するために名前クエリ操作を実行する必要があります。（この情報は、後続のNetBiosデータグラムの名前クエリのオーバーヘッドを避けるためにキャッシュされる場合があります。）
17.1.1. UNICAST, MULTICAST, AND BROADCAST
17.1.1. ユニキャスト、マルチキャスト、ブロードキャスト
NetBIOS datagrams may be unicast, multicast, or broadcast. A NetBIOS datagram addressed to a unique NetBIOS name is unicast. A NetBIOS datagram addressed to a group NetBIOS name, whether there are zero, one, or more actual members, is multicast. A NetBIOS datagram sent using the NetBIOS "Send Broadcast Datagram" primitive is broadcast.
NetBiosデータグラムは、ユニキャスト、マルチキャスト、またはブロードキャストです。一意のnetBios名に宛てられたnetBiosデータグラムはユニキャストです。netBiosデータグラムは、ゼロ、1つ、またはそれ以上の実際のメンバーがあるかどうかにかかわらず、グループNetBios名にアドレス指定されています。netBios "send datagramの送信" Primitiveを使用して送信されたNetBiosデータグラムがブロードキャストされます。
17.1.2. FRAGMENTATION OF NetBIOS DATAGRAMS
17.1.2. netBiosデータグラムの断片化
When the header and data of a NetBIOS datagram exceeds the maximum amount of data allowed in a UDP packet, the NetBIOS datagram must be fragmented before transmission and reassembled upon receipt.
NetBiosデータグラムのヘッダーとデータがUDPパケットで許可される最大量のデータを超える場合、NetBiosデータグラムは送信前に断片化し、受領時に再組み立てする必要があります。
A NetBIOS Datagram is composed of the following protocol elements:
NetBiosデータグラムは、次のプロトコル要素で構成されています。
- IP header of 20 bytes (minimum) - UDP header of 8 bytes - NetBIOS Datagram Header of 14 bytes - The NetBIOS Datagram data.
- 20バイトのIPヘッダー（最小） - 8バイトのUDPヘッダー - 14バイトのNetBiosデータグラムヘッダー - NetBiosデータグラムデータ。
18. NODE CONFIGURATION PARAMETERS
18. ノード構成パラメーター
- B NODES: - Node's permanent unique name - Whether IGMP is in use - Broadcast IP address to use - Whether NetBIOS session keep-alives are needed - Usable UDP data field length (to control fragmentation) - P NODES: - Node's permanent unique name - IP address of NBNS - IP address of NBDD - Whether NetBIOS session keep-alives are needed - Usable UDP data field length (to control fragmentation) - M NODES: - Node's permanent unique name - Whether IGMP is in use - Broadcast IP address to use - IP address of NBNS - IP address of NBDD - Whether NetBIOS session keep-alives are needed - Usable UDP data field length (to control fragmentation)
- Bノード： - ノードの永続的な一意名 - IGMPが使用されているかどうか - 使用するブロードキャストIPアドレス - NetBiosセッションKEEP -ALIVESが必要かどうか - 使用可能なUDPデータフィールド長（断片化を制御する） - Pノード： - ノードの永続的な一意の名前 - NBNSのIPアドレス-NBDDのIPアドレス - NetBiosセッションKEEP -ALIVESが必要かどうか - 使用可能なUDPデータフィールド長さ（断片化を制御するため）-Mノード： - ノードの永続的な一意の名前 - IGMPが使用しているかどうか - 使用するブロードキャストIPアドレス-NBNSのIPアドレス-NBDDのIPアドレス - NetBiosセッションKeep -Alivesが必要かどうか - 使用可能なUDPデータフィールド長（断片化を制御するため）
All of the proceeding sections make implicit use of IPv4 addresses and a new specification should be defined for use of IPv6 underlying addresses.
すべての手続きセクションでは、IPv4アドレスを暗黙的に使用し、IPv6基礎となるアドレスを使用するために新しい仕様を定義する必要があります。
3.4.2. RFC 1002 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS
3.4.2. TCP/UDP輸送に関するNetBiosサービスのRFC1002プロトコル標準：詳細な仕様
Section 4.2.1.3. RESOURCE RECORD defines
セクション4.2.1.3。リソースレコードが定義します
RESOURCE RECORD RR_TYPE field definitions:
リソースレコードRR_TYPEフィールド定義：
Symbol Value Description:
記号値の説明：
A 0x0001 IP address Resource Record (See REDIRECT NAME QUERY RESPONSE)
0x0001 IPアドレスリソースレコード（リダイレクト名クエリ応答を参照）
Sections 4.2.2. NAME REGISTRATION REQUEST, 4.2.3. NAME OVERWRITE REQUEST & DEMAND, 4.2.4. NAME REFRESH REQUEST, 4.2.5. POSITIVE NAME REGISTRATION RESPONSE, 4.2.6. NEGATIVE NAME REGISTRATION RESPONSE, 4.2.7. END-NODE CHALLENGE REGISTRATION RESPONSE, 4.2.9. NAME RELEASE REQUEST & DEMAND, 4.2.10. POSITIVE NAME RELEASE RESPONSE, 4.2.11. NEGATIVE NAME RELEASE RESPONSE and Sections 4.2.13. POSITIVE NAME QUERY RESPONSE all contain 32 bit fields labeled "NB_ADDRESS" clearly defined for IPv4 addresses Sections 4.2.15. REDIRECT NAME QUERY RESPONSE contains a field "NSD_IP_ADDR" which also is designed for a IPv4 address.
セクション4.2.2。名前登録リクエスト、4.2.3。名前を上書きリクエストと需要、4.2.4。名前の更新リクエスト、4.2.5。正の名前登録応答、4.2.6。ネガティブ名登録応答、4.2.7。エンドノードチャレンジ登録応答、4.2.9。名前のリリースリクエストと需要、4.2.10。ポジティブネームリリース応答、4.2.11。ネガティブ名のリリース応答とセクション4.2.13。正の名前クエリ応答はすべて、IPv4アドレスセクション4.2.15で明確に定義されている「NB_Address」というラベルのある32ビットフィールドを含みます。リダイレクト名クエリ応答には、IPv4アドレス用に設計されたフィールド「NSD_IP_ADDR」が含まれています。
Section 4.3.5. SESSION RETARGET RESPONSE PACKET
セクション4.3.5。セッションリターゲット応答パケット
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RETARGET_IP_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.1. NetBIOS DATAGRAM HEADER
セクション4.4.1。netbiosデータグラムヘッダー
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.2. DIRECT_UNIQUE, DIRECT_GROUP, & BROADCAST DATAGRAM
セクション4.4.2。Direct_unique、Direct Group、およびBroadcast Datagram
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ SOURCE_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ USER_DATA /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.3. DATAGRAM ERROR PACKET
セクション4.4.3。データグラムエラーパケット
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | ERROR_CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.4. DATAGRAM QUERY REQUEST
セクション4.4.4。データグラムクエリリクエスト
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4.5. DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE
4.4.5. データグラムポジティブおよびネガティブクエリ応答
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. NetBIOS DATAGRAM SERVICE PROTOCOLS
5.3. NetBiosデータグラムサービスプロトコル
The following are GLOBAL variables and should be NetBIOS user configurable:
以下はグローバル変数であり、NetBiosユーザーの構成可能である必要があります。
- BROADCAST_ADDRESS: the IP address B-nodes use to send datagrams with group name destinations and broadcast datagrams. The default is the IP broadcast address for a single IP network.
- broadcast_address：IPアドレスb-nodesは、グループ名の宛先とブロードキャストデータグラムを備えたデータグラムを送信するために使用します。デフォルトは、単一のIPネットワークのIPブロードキャストアドレスです。
There is also a large amount of pseudo code for most of the protocols functionality that make no specific reference to IPv4 addresses. However they assume the use of the above defined packets. The pseudo code may be valid for IPv6 as long as the packet formats are updated.
また、ほとんどのプロトコル機能には、IPv4アドレスを具体的に参照しない大量の擬似コードもあります。ただし、上記の定義されたパケットの使用を想定しています。パケット形式が更新されている限り、擬似コードはIPv6に有効になる場合があります。
Section 5. The Protocol defines a mapping specification
セクション5.プロトコルは、マッピング仕様を定義します
Mapping parameters is also straight-forward:
マッピングパラメーターも簡単です。
network service TCP
------- ---
CONNECTION RELEASE
Called address server's IP address (4 octets)
アドレスサーバーのIPアドレス（4オクテット）と呼ばれる
Calling address client's IP address (4 octets)
アドレスクライアントのIPアドレス（4オクテット）を呼び出す
Draft Standards represent the penultimate standard level in the IETF. A protocol can only achieve draft standard when there are multiple, independent, interoperable implementations. Draft Standards are usually quite mature and widely used.
ドラフト標準は、IETFの最後から2番目の標準レベルを表しています。プロトコルは、複数の独立した相互運用可能な実装がある場合にのみ、ドラフト標準を達成できます。ドラフト基準は通常、非常に成熟しており、広く使用されています。
4.1. RFC 3530 Network File System (NFS) version 4 Protocol
4.1. RFC 3530ネットワークファイルシステム（NFS）バージョン4プロトコル
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
4.2. RFC 3550 RTP: A Transport Protocol for Real-Time Applications
4.2. RFC 3550 RTP：リアルタイムアプリケーション用のトランスポートプロトコル
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
4.3. RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control.
4.3. RFC 3551オーディオおよびビデオ会議用のRTPプロファイルが最小限の制御を伴います。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
Proposed Standards are introductory level documents. There are no requirements for even a single implementation. In many cases Proposed are never implemented or advanced in the IETF standards process. They therefore are often just proposed ideas that are presented to the Internet community. Sometimes flaws are exposed or they are one of many competing solutions to problems. In these later cases, no discussion is presented as it would not serve the purpose of this discussion.
提案された標準は、入門レベルの文書です。単一の実装にも要件はありません。多くの場合、提案されていることは、IETF標準プロセスで実装または前進することはありません。したがって、それらは多くの場合、インターネットコミュニティに提示される提案されたアイデアです。欠陥が暴露されることもあれば、問題に対する多くの競合する解決策の1つです。これらの後のケースでは、この議論の目的に役立たないため、議論は提示されません。
5.01. RFC 1144 Compressing TCP/IP headers for low-speed serial links
5.01. RFC 1144低速シリアルリンク用のTCP/IPヘッダーの圧縮
This RFC is specifically oriented towards TCP/IPv4 packet headers and will not work in it's current form. Significant work has already been done on similar algorithms for TCP/IPv6 headers.
このRFCは、特にTCP/IPv4パケットヘッダーに向けられており、現在の形式では機能しません。TCP/IPv6ヘッダーの同様のアルゴリズムでは、すでに重要な作業が行われています。
5.02. RFC 1323 TCP Extensions for High Performance
5.02. RFC 1323高性能のためのTCP拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.03. RFC 1553 Compressing IPX Headers Over WAN Media (CIPX)
5.03. RFC 1553 WANメディア上のIPXヘッダーを圧縮する（CIPX）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.04. RFC 1692 Transport Multiplexing Protocol (TMux)
5.04. RFC 1692トランスポートマルチプレックスプロトコル（TMUX）
Section 6. Implementation Notes is states:
セクション6.実装ノートは状態です。
Because the TMux mini-header does not contain a TOS field, only segments with the same IP TOS field should be contained in a single TMux message. As most systems do not use the TOS feature, this is not a major restriction. Where the TOS field is used, it may be desirable to hold several messages under construction for a host, one for each TOS value.
TMUXミニヘッダーにはTOSフィールドが含まれていないため、同じIP TOSフィールドを持つセグメントのみを単一のTMUXメッセージに含める必要があります。ほとんどのシステムはTOS機能を使用していないため、これは大きな制限ではありません。TOSフィールドが使用される場合、各TOS値に1つずつ、ホストのためにいくつかのメッセージを構築中に保持することが望ましい場合があります。
Segments containing IP options should not be multiplexed.
IPオプションを含むセグメントを多重化しないでください。
This is clearly IPv4 specific, but a simple restatement in IPv6 terms will allow complete functionality.
これは明らかにIPv4固有ですが、IPv6用語での単純な修正により、完全な機能が可能になります。
5.05. RFC 1831 RPC: Remote Procedure Call Protocol Specification Version 2 RPC
5.05. RFC 1831 RPC：リモートプロシージャコールプロトコル仕様バージョン2 RPC
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.06. RFC 1833 Binding Protocols for ONC RPC Version 2
5.06. RFC 1833 ONC RPCバージョン2の結合プロトコル
In Section 2.1 RPCBIND Protocol Specification (in RPC Language) there is the following code fragment:
セクション2.1 RPCBINDプロトコル仕様（RPC言語）には、次のコードフラグメントがあります。
* Protocol family (r_nc_protofmly): * This identifies the family to which the protocol belongs. * The following values are defined: * NC_NOPROTOFMLY "-" * NC_LOOPBACK "loopback" * NC_INET "inet" * NC_IMPLINK "implink" * NC_PUP "pup" * NC_CHAOS "chaos" * NC_NS "ns" * NC_NBS "nbs" * NC_ECMA "ecma" * NC_DATAKIT "datakit" * NC_CCITT "ccitt" * NC_SNA "sna" * NC_DECNET "decnet" * NC_DLI "dli" * NC_LAT "lat" * NC_HYLINK "hylink" * NC_APPLETALK "appletalk" * NC_NIT "nit" * NC_IEEE802 "ieee802" * NC_OSI "osi" * NC_X25 "x25" * NC_OSINET "osinet" * NC_GOSIP "gosip"
* プロトコルファミリー（R_NC_ProtofMly）： *これは、プロトコルが属するファミリーを識別します。*次の値が定義されています： * nc_noprotofmly " - " * nc_loopback "loopback" * nc_inet "inet" * nc_implink " * nc_pup" pup " * nc_chaos" chaos " * nc_ns" ns " * nc_nbs" nc_nbs " * nc_ecma"ecma " * nc_datakit" datakit " * nc_ccitt" ccitt " * nc_sna" sna " * nc_decnet" decnet " * nc_dli" dli " * nc_lat" lat "lat" * nc_hylink "hylink" * nc_appleeet "" nc_nit "" nc_nit "" nc_nit " * nc_nit" * nc_nitIEEE802 " * NC_OSI" OSI " * nc_x25" x25 " * nc_osinet" osinet " * nc_gosip" gosip "
It is clear that the value for NC_INET is intended for the IP protocol and is seems clear that it is IPv4 dependent.
NC_INETの値がIPプロトコルを対象としていることは明らかであり、IPv4に依存していることは明らかです。
5.07. RFC 1962 The PPP Compression Control Protocol (CCP)
5.07. RFC 1962 PPP圧縮制御プロトコル（CCP）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.08. RFC 2018 TCP Selective Acknowledgement Options
5.08. RFC 2018 TCP選択的承認オプション
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.09. RFC 2029 RTP Payload Format of Sun's CellB Video Encoding
5.09. RFC 2029 RTP SunのCellbビデオエンコーディングのペイロード形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.10. RFC 2032 RTP Payload Format for H.261 Video Streams
5.10. RFC 2032 H.261ビデオストリームのRTPペイロード形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.11. RFC 2126 ISO Transport Service on top of TCP (ITOT)
5.11. TCPの上にあるRFC 2126 ISO輸送サービス（ITOT）
This specification is IPv6 aware and has no issues.
この仕様はIPv6が認識しており、問題はありません。
5.12. RFC 2190 RTP Payload Format for H.263 Video Streams
5.12. H.263ビデオストリームのRFC 2190 RTPペイロード形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.13. RFC 2198 RTP Payload for Redundant Audio Data
5.13. RFC 2198 RTP冗長なオーディオデータのペイロード
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.14. RFC 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
5.14. RFC 2205リソース予約プロトコル（RSVP） - バージョン1機能仕様
In Section 1. Introduction the statement is made:
セクション1.はじめにステートメントが作成されます。
RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack.
RSVPはIPv4またはIPv6の上で動作し、プロトコルスタック内の輸送プロトコルの場所を占めています。
Appendix A defines all of the header formats for RSVP and there are multiple formats for both IPv4 and IPv6.
付録Aでは、RSVPのすべてのヘッダー形式を定義し、IPv4とIPv6の両方に複数の形式があります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.15. RFC 2207 RSVP Extensions for IPSEC Data Flows
5.15. IPSECデータフロー用のRFC 2207 RSVP拡張機能
The defined IPsec extensions are valid for both IPv4 & IPv6. There are no IPv4 dependencies in this specification.
定義されたIPSEC拡張機能は、IPv4とIPv6の両方で有効です。この仕様にはIPv4依存関係はありません。
5.16. RFC 2210 The Use of RSVP with IETF Integrated Services
5.16. RFC 2210 IETF統合サービスでRSVPの使用
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.17. RFC 2211 Specification of the Controlled-Load Network Element Service
5.17. RFC 2211制御されたロードネットワーク要素サービスの仕様
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.18. RFC 2212 Specification of Guaranteed Quality of Service
5.18. RFC 2212保証されたサービス品質の仕様
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.19. RFC 2215 General Characterization Parameters for Integrated Service Network Elements
5.19. RFC 2215統合サービスネットワーク要素の一般的な特性評価パラメーター
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.20. RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video
5.20. MPEG1/MPEG2ビデオのRFC2250 RTPペイロード形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.21. RFC 2326 Real Time Streaming Protocol (RTSP)
5.21. RFC 2326リアルタイムストリーミングプロトコル（RTSP）
Section 3.2 RTSP URL defines:
セクション3.2 RTSP URLは次のことを定義します。
The "rtsp" and "rtspu" schemes are used to refer to network resources via the RTSP protocol. This section defines the scheme-specific syntax and semantics for RTSP URLs.
「RTSP」および「RTSPU」スキームは、RTSPプロトコルを介してネットワークリソースを参照するために使用されます。このセクションでは、RTSP URLのスキーム固有の構文とセマンティクスを定義します。
rtsp_URL = ( "rtsp:" | "rtspu:" )
"//" host [ ":" port ] [ abs_path ]
host = <A legal Internet host domain name of IP
address (in dotted decimal form), as defined
by Section 2.1 of RFC 1123 \cite{rfc1123}>
port = *DIGIT
Although later in that section the following text is added:
そのセクションの後半では、次のテキストが追加されています。
The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1924 [19]).
URLでのIPアドレスの使用は、可能な限り回避する必要があります（RFC 1924 [19]を参照）。
Some later examples show:
いくつかの後の例は次のように示しています：
Example:
例：
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl,
application/mheg
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
which implies the use of the "IP4" tag and it should be possible to use an "IP6" tag. There are also numerous other similar examples using the "IP4" tag.
これは、「IP4」タグの使用を意味し、「IP6」タグを使用できるはずです。「IP4」タグを使用して、他にも多くの同様の例があります。
RTSP is also dependent on IPv6 support in a protocol capable of describing media configurations, for example SDP RFC 2327.
RTSPは、SDP RFC 2327など、メディア構成を記述できるプロトコルのIPv6サポートにも依存しています。
RTSP can be used over IPv6 as long as the media description protocol supports IPv6, but only for certain restricted use cases. For full functionality there is need for IPv6 support. The amount of updates needed are small.
RTSPは、メディアの説明プロトコルがIPv6をサポートしている限り、IPv6を介して使用できますが、特定の制限されたユースケースでのみ使用できます。完全な機能については、IPv6サポートが必要です。必要な更新の量は少ないです。
5.22. RFC 2327 SDP: Session Description Protocol (SDP)
5.22. RFC 2327 SDP：セッション説明プロトコル（SDP）
This specification is under revision, and IPv6 support was added in RFC 3266 which updates this specification.
この仕様は改訂中で、IPv6サポートがRFC 3266に追加され、この仕様を更新しました。
5.23. RFC 2380 RSVP over ATM Implementation Requirements
5.23. ATM実装要件を介したRFC 2380 RSVP
This specification is both IPv4 and IPv6 aware.
この仕様は、IPv4とIPv6の両方の認識です。
5.24. RFC 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM
5.24. RFC 2381制御ロードサービスの相互操作とATMとの保証サービス
There does not seem any inherent IPv4 limitations in this specification, but it assumes work of other standards that have IPv4 limitations.
この仕様には固有のIPv4制限はないようですが、IPv4の制限がある他の標準の作業を想定しています。
5.25. RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)
5.25. RFC 2429 RTP 1998バージョンのITU-T Rec。H.263ビデオ（H.263）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.26. RFC 2431 RTP Payload Format for BT.656 Video Encoding
5.26. RFC 2431 BT.656ビデオエンコーディング用のRTPペイロード形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.27. RFC 2435 RTP Payload Format for JPEG-compressed Video
5.27. JPEG圧縮ビデオ用のRFC 2435 RTPペイロード形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.28. RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
5.28. RFC 2474 IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義
This specification is both IPv4 and IPv6 aware.
この仕様は、IPv4とIPv6の両方の認識です。
5.29. RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
5.29. RFC 2508低速シリアルリンク用のIP/UDP/RTPヘッダーの圧縮
This specification is both IPv4 and IPv6 aware.
この仕様は、IPv4とIPv6の両方の認識です。
5.30. RFC 2581 TCP Congestion Control
5.30. RFC 2581 TCP混雑制御
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.31. RFC 2597 Assured Forwarding PHB Group
5.31. RFC 2597 Assured PHB Group
This specification is both IPv4 and IPv6 aware.
この仕様は、IPv4とIPv6の両方の認識です。
5.32. RFC 2658 RTP Payload Format for PureVoice(tm) Audio
5.32. RFC 2658 RTP PureVoice（TM）オーディオ用のペイロード形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.33. RFC 2678 IPPM Metrics for Measuring Connectivity
5.33. RFC 2678接続を測定するためのIPPMメトリック
This specification only supports IPv4.
この仕様はIPv4のみをサポートします。
5.34. RFC 2679 A One-way Delay Metric for IPPM
5.34. RFC 2679 IPPMの一元配置遅延メトリック
This specification only supports IPv4.
この仕様はIPv4のみをサポートします。
5.35. RFC 2680 A One-way Packet Loss Metric for IPPM
5.35. RFC 2680 IPPMの一元配置パケット損失メトリック
This specification only supports IPv4.
この仕様はIPv4のみをサポートします。
5.36. RFC 2681 A Round-trip Delay Metric for IPPM
5.36. RFC 2681 IPPMの往復遅延メトリック
This specification only supports IPv4.
この仕様はIPv4のみをサポートします。
5.37. RFC 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP)
5.37. RFC 2730マルチキャストアドレスダイナミッククライアント割り当てプロトコル（MADCAP）
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
5.38. RFC 2733 An RTP Payload Format for Generic Forward Error Correction
5.38. RFC 2733ジェネリックフォワードエラー修正用のRTPペイロード形式
This specification is dependent on SDP which has IPv4 dependencies. Once that limitation is fixed, then this specification should support IPv6.
この仕様は、IPv4依存関係を持つSDPに依存します。その制限が修正されると、この仕様はIPv6をサポートする必要があります。
5.39. RFC 2745 RSVP Diagnostic Messages
5.39. RFC 2745 RSVP診断メッセージ
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
5.40. RFC 2746 RSVP Operation Over IP Tunnels
5.40. RFC 2746 IPトンネル上のRSVP操作
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
5.41. RFC 2750 RSVP Extensions for Policy Control
5.41. RFC 2750 RSVP拡張機能のための拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.42. RFC 2793 RTP Payload for Text Conversation
5.42. RFC 2793 RTPテキスト会話のペイロード
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.43. RFC 2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks
5.43. RFC 2814 SBM（Subnet Bandwidth Manager）：IEEE 802スタイルのネットワークに対するRSVPベースの入場制御のプロトコル
This specification claims to be both IPv4 and IPv6 aware, but all of the examples are given with IPv4 addresses. That, by itself is not a telling point but the following statement is made:
この仕様は、IPv4とIPv6の両方が認識されていると主張していますが、すべての例はIPv4アドレスで示されています。それ自体はそれだけではありませんが、次の声明がなされます。
a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, 0.0.0.0) and priority. All IP addresses are assumed to be in network byte order. In addition, current DSBM's L2 address is also stored as part of this state information.
a) localdsbmaddrinfo-現在のDSBMのIPアドレス（最初は0.0.0.0）および優先度。すべてのIPアドレスは、ネットワークバイトの順序であると想定されています。さらに、現在のDSBMのL2アドレスは、この州情報の一部として保存されています。
which could just be sloppy wording. Perhaps a short document clarifying the text is appropriate.
ずさんな言葉遣いである可能性があります。おそらく、テキストを明確にする短いドキュメントが適切です。
5.44. RFC 2815 Integrated Service Mappings on IEEE 802 Networks
5.44. RFC 2815 IEEE 802ネットワークの統合サービスマッピング
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.45. RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
5.45. RFC 2833 DTMF桁、テレフォニートーン、テレフォニー信号のRTPペイロード
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.46. RFC 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services
5.46. RFC 2848パイントサービスプロトコル：電話へのIPアクセスのためのSIPおよびSDPへの拡張
This specification is dependent on SDP which has IPv4 dependencies. Once these limitations are fixed, then this specification should support IPv6.
この仕様は、IPv4依存関係を持つSDPに依存します。これらの制限が修正されると、この仕様はIPv6をサポートする必要があります。
5.47. RFC 2862 RTP Payload Format for Real-Time Pointers
5.47. RFC 2862 RTPリアルタイムポインター用のペイロード形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.48. RFC 2872 Application and Sub Application Identity Policy Element for Use with RSVP
5.48. RSVPで使用するためのRFC 2872アプリケーションとサブアプリケーションIDポリシー要素
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.49. RFC 2873 TCP Processing of the IPv4 Precedence Field
5.49. RFC 2873 TCP IPv4優先順位フィールドの処理
This specification documents a technique using IPv4 headers. A similar technique, if needed, will need to be defined for IPv6.
この仕様は、IPv4ヘッダーを使用して手法を文書化します。同様の手法は、必要に応じて、IPv6に対して定義する必要があります。
5.50. RFC 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP
5.50. RFC 2883 TCPの選択的承認（sack）オプションへの拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.51. RFC 2907 MADCAP Multicast Scope Nesting State Option
5.51. RFC 2907 MADCAPマルチキャストスコープネスティング状態オプション
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
5.52. RFC 2960 Stream Control Transmission Protocol
5.52. RFC 2960ストリーム制御伝送プロトコル
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
5.53. RFC 2961 RSVP Refresh Overhead Reduction Extensions
5.53. RFC 2961 RSVPリフレッシュオーバーヘッド削減延長
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
5.54. RFC 2976 The SIP INFO Method
5.54. RFC 2976 SIP情報方法
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.55. RFC 2988 Computing TCP's Retransmission Timer
5.55. RFC 2988コンピューティングTCPの再送信タイマー
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.56. RFC 2996 Format of the RSVP DCLASS Object
5.56. RSVP DCLASSオブジェクトのRFC 2996形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.57. RFC 2997 Specification of the Null Service Type
5.57. RFC 2997 NULLサービスタイプの仕様
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.58. RFC 3003 The audio/mpeg Media Type
5.58. RFC 3003オーディオ/MPEGメディアタイプ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.59. RFC 3006 Integrated Services in the Presence of Compressible Flows
5.59. RFC 3006圧縮性フローの存在下での統合サービス
This document defines a protocol that discusses compressible flows, but only in an IPv4 context. When IPv6 compressible flows are defined, a similar technique should also be defined.
このドキュメントでは、圧縮性フローについて議論するプロトコルを定義しますが、IPv4コンテキストでのみです。IPv6圧縮性フローが定義されている場合、同様の手法も定義する必要があります。
5.60. RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams
5.60. MPEG-4オーディオ/ビジュアルストリームのRFC 3016 RTPペイロード形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.61. RFC 3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol
5.61. RFC 3033インターネットプロトコルのQ.2941ジェネリック識別子とQ.2957ユーザーツーユーザーシグナリングにおける情報フィールドとプロトコル識別子の割り当て
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
5.62. RFC 3042 Enhancing TCP's Loss Recovery Using Limited Transmit
5.62. RFC 3042が限られた送信を使用したTCPの損失回復を強化する
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.63. RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1
5.63. RFC 3047 RTP ITU-T推奨のためのペイロード形式G.722.1
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.64. RFC 3057 ISDN Q.921-User Adaptation Layer
5.64. RFC 3057 ISDN Q.921-USER適応層
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.65. RFC 3095 Robust Header Compression (ROHC): Framework and four profiles
5.65. RFC 3095堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
5.66. RFC 3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections
5.66. ATMベアラー接続のセッション説明プロトコル（SDP）の使用のためのRFC 3108コンベンション
This specification is currently limited to IPv4 as amplified below:
この仕様は現在、以下に増幅されるようにIPv4に限定されています。
The range and format of the <rtcpPortNum> and <rtcpIPaddr> subparameters is per [1]. The <rtcpPortNum> is a decimal number between 1024 and 65535. It is an odd number. If an even number in this range is specified, the next odd number is used. The <rtcpIPaddr> is expressed in the usual dotted decimal IP address representation, from 0.0.0.0 to 255.255.255.255.
<rtcpportnum>および<rtcpipaddr>サブパラメーターの範囲と形式は[1]ごとです。<rtcpportnum>は、1024から65535の10進数です。奇数です。この範囲の偶数が指定されている場合、次の奇数が使用されます。<rtcpipaddr>は、0.0.0.0から255.255.255.255の通常の点線の小数IPアドレス表現で表されます。
and
そして
<rtcpIPaddr> IP address for receipt Dotted decimal, 7-15 chars of RTCP packets
<RTCPIPADDR>領収書用点線のIPアドレス、RTCPパケットの7-15 charsの7-15 char
5.67. RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio
5.67. RFC 3119 MP3オーディオ用のより損失耐性RTPペイロード形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.68. RFC 3124 The Congestion Manager
5.68. RFC 3124混雑マネージャー
This document is IPv4 limited since it uses the IPv4 TOS header field.
このドキュメントは、IPv4 TOSヘッダーフィールドを使用しているため、IPv4 Limitedです。
5.69. RFC 3140 Per Hop Behavior Identification Codes
5.69. RFC 3140ホップの動作識別コード
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.70. RFC 3173 IP Payload Compression Protocol (IPComp)
5.70. RFC 3173 IPペイロード圧縮プロトコル（IPComp）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.71. RFC 3181 Signaled Preemption Priority Policy Element
5.71. RFC 3181は、先行予約優先度のポリシー要素を合図しました
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.72. RFC 3182 Identity Representation for RSVP
5.72. RSVPのRFC 3182アイデンティティ表現
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.73. RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior)
5.73. RFC 3246迅速な転送PHB（ホップごとの動作）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.74. RFC 3261 SIP: Session Initiation Protocol
5.74. RFC 3261 SIP：セッション開始プロトコル
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.75. RFC 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP)
5.75. RFC 3262セッション開始プロトコル（SIP）における暫定的な応答の信頼性
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.76. RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers
5.76. RFC 3263セッション開始プロトコル（SIP）：SIPサーバーの位置
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.77. RFC 3264 An Offer/Answer Model with Session Description Protocol (SDP)
5.77. RFC 3264セッション説明プロトコル（SDP）を使用したオファー/回答モデル
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.78. RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification
5.78. RFC 3265セッション開始プロトコル（SIP） - 特異的イベント通知
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.79. RFC 3390 Increasing TCP's Initial Window
5.79. RFC 3390 TCPの初期ウィンドウの増加
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.80. RFC 3525 Gateway Control Protocol Version 1
5.80. RFC 3525ゲートウェイ制御プロトコルバージョン1
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.81. RFC 3544 IP Header Compression over PPP
5.81. RFC 3544 PPP上のIPヘッダー圧縮
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
Experimental RFCs typically define protocols that do not have widescale implementation or usage on the Internet. They are often propriety in nature or used in limited arenas. They are documented to the Internet community in order to allow potential interoperability or some other potential useful scenario. In a few cases they are presented as alternatives to the mainstream solution to an acknowledged problem.
通常、実験的なRFCは、インターネット上での幅広い実装や使用法を持たないプロトコルを定義します。それらはしばしば本質的に礼儀正しさであるか、限られた分野で使用されています。それらは、潜在的な相互運用性またはその他の潜在的な有用なシナリオを可能にするために、インターネットコミュニティに文書化されています。いくつかのケースでは、認められた問題の主流の解決策の代替として提示されています。
6.1. RFC 908 Reliable Data Protocol (RDP)
6.1. RFC 908信頼できるデータプロトコル（RDP）
This document is IPv4 limited as stated in the following section:
このドキュメントは、次のセクションに記載されているようにIPv4 Limitedです。
4.1. IP Header Format
4.1. IPヘッダー形式
When used in the internet environment, RDP segments are sent using the version 4 IP header as described in RFC791, "Internet Protocol." The RDP protocol number is ??? (decimal). The time-to-live field should be set to a reasonable value for the network.
インターネット環境で使用する場合、RDPセグメントは、RFC791「Internet Protocol」で説明されているバージョン4 IPヘッダーを使用して送信されます。RDPプロトコル番号は???（小数）。時間のフィールドは、ネットワークの合理的な価値に設定する必要があります。
All other fields should be set as specified in RFC-791.
他のすべてのフィールドは、RFC-791で指定されているように設定する必要があります。
A new protocol specification would be needed to support IPv6.
IPv6をサポートするには、新しいプロトコル仕様が必要になります。
6.02. RFC 938 Internet Reliable Transaction Protocol functional and interface specification (IRTP)
6.02. RFC 938インターネット信頼できるトランザクションプロトコル機能およびインターフェイス仕様（IRTP）
This specification states:
この仕様は次のとおりです。
4.1. State Variables
4.1. 状態変数
Each IRTP is associated with a single internet address. The synchronization mechanism of the IRTP depends on the requirement that each IRTP module knows the internet addresses of all modules with which it will communicate. For each remote internet address, an IRTP module must maintain the following information (called the connection table):
各IRTPは、単一のインターネットアドレスに関連付けられています。IRTPの同期メカニズムは、各IRTPモジュールが通信するすべてのモジュールのインターネットアドレスを知っているという要件に依存します。リモートインターネットアドレスごとに、IRTPモジュールは次の情報（接続テーブルと呼ばれる）を維持する必要があります。
rem_addr (32 bit remote internet address)
rem_addr（32ビットリモートインターネットアドレス）
A new specification that is IPv6 aware would need to be created.
IPv6を認識している新しい仕様を作成する必要があります。
6.03. RFC 998 NETBLT: A bulk data transfer protocol
6.03. RFC 998 NetBlt：バルクデータ転送プロトコル
This RFC states:
このRFCは次のように述べています
The active end specifies a passive client through a client-specific "well-known" 16 bit port number on which the passive end listens. The active end identifies itself through a 32 bit Internet address and a unique 16 bit port number.
アクティブエンドは、パッシブエンドが耳を傾けるクライアント固有の「よく知られている」16ビットポート番号を介してパッシブクライアントを指定します。Active Endは、32ビットのインターネットアドレスと一意の16ビットポート番号を介してそれ自体を識別します。
Clearly, this is IPv4 dependent, but could easily be modified to support IPv6 addressing.
明らかに、これはIPv4依存ですが、IPv6アドレス指定をサポートするように簡単に変更できます。
6.04. RFC 1045 VMTP: Versatile Message Transaction Protocol
6.04. RFC 1045 VMTP：汎用メッセージトランザクションプロトコル
This specification has many IPv4 dependencies in its implementation appendices. For operations over IPv6 a similar implementation procedure must be defined. The IPv4 specific information is show below.
この仕様には、実装付録に多くのIPv4依存関係があります。IPv6を介した操作の場合、同様の実装手順を定義する必要があります。IPv4固有の情報を以下に示します。
IV.1. Domain 1
IV.1。ドメイン1
For initial use of VMTP, we define the domain with Domain identifier 1 as follows:
VMTPを初期に使用するために、ドメイン識別子1を使用してドメインを次のように定義します。
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Address |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
The Internet address is the Internet address of the host on which this entity-id is originally allocated. The Discriminator is an arbitrary value that is unique relative to this Internet host address. In addition, the host must guarantee that this identifier does not get reused for a long period of time after it becomes invalid. ("Invalid" means that no VMTP module considers in bound to an entity.) One technique is to use the lower order bits of a 1 second clock. The clock need not represent real-time but must never be set back after a crash. In a simple implementation, using the low order bits of a clock as the time stamp, the generation of unique identifiers is overall limited to no more than 1 per second on average. The type flags were described in Section 3.1.
インターネットアドレスは、このエンティティIDが元々割り当てられたホストのインターネットアドレスです。判別器は、このインターネットホストアドレスに比べて一意の任意の値です。さらに、ホストは、この識別子が無効になってから長期間再利用されないことを保証する必要があります。（「無効」とは、VMTPモジュールがエンティティにバインドされていると考慮しないことを意味します。）1つの手法は、1秒のクロックの低次ビットを使用することです。クロックはリアルタイムを表す必要はありませんが、クラッシュした後は決して後退してはなりません。単純な実装では、クロックの低次ビットをタイムスタンプとして使用して、ユニークな識別子の生成は全体で平均して1秒あたり1秒以下に制限されています。タイプフラグはセクション3.1で説明されています。
An entity may migrate between hosts. Thus, an implementation can heuristically use the embedded Internet address to locate an entity but should be prepared to maintain a cache of redirects for migrated entities, plus accept Notify operations indicating that migration has occurred.
エンティティはホスト間で移動する場合があります。したがって、実装は、組み込みインターネットアドレスをヒューリスティックに使用してエンティティを特定できますが、移行エンティティのリダイレクトのキャッシュを維持する準備をする必要があります。また、移行が発生したことを示す通知操作を受け入れる必要があります。
Entity group identifiers in Domain 1 are structured in one of two forms, depending on whether they are well-known or dynamically allocated identifiers. A well-known entity identifier is structured as:
ドメイン1のエンティティグループ識別子は、よく知られているか動的に割り当てられた識別子であるかに応じて、2つの形式のいずれかで構成されています。よく知られているエンティティ識別子は、次のように構成されています。
+-----------+----------------+------------------------+
| TypeFlags | Discriminator |Internet Host Group Addr|
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
with the second high-order bit (GRP) set to 1. This form of entity identifier is mapped to the Internet host group address specified in the low-order 32 bits. The Discriminator distinguishes group identifiers using the same Internet host group. Well-known entity group identifiers should be allocated to correspond to the basic services provided by hosts that are members of the group, not specifically because that service is provided by VMTP. For example, the well-known entity group identifier for the domain name service should contain as its embedded Internet host group address the host group for Domain Name servers.
2番目の高次ビット（GRP）が1に設定されています。この形式のエンティティ識別子は、低次32ビットで指定されたインターネットホストグループアドレスにマッピングされます。判別器は、同じインターネットホストグループを使用してグループ識別子を区別します。特に、そのサービスがVMTPによって提供されるためではなく、グループのメンバーであるホストが提供する基本サービスに対応するように、有名なエンティティグループ識別子は割り当てられる必要があります。たとえば、ドメイン名サービスの有名なエンティティグループ識別子には、埋め込まれたインターネットホストグループがドメイン名サーバーのホストグループにアドレスしているように含める必要があります。
A dynamically allocated entity identifier is structured as:
動的に割り当てられたエンティティ識別子は、次のように構成されています。
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Host Addr |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
with the second high-order bit (GRP) set to 1. The Internet address in the low-order 32 bits is a Internet address assigned to the host that dynamically allocates this entity group identifier. A dynamically allocated entity group identifier is mapped to Internet host group address 232.X.X.X where X.X.X are the low-order 24 bits of the Discriminator subfield of the entity group identifier.
2番目の高次ビット（GRP）が1に設定されています。低次の32ビットのインターネットアドレスは、このエンティティグループ識別子を動的に割り当てるホストに割り当てられたインターネットアドレスです。動的に割り当てられたエンティティグループ識別子は、インターネットホストグループアドレス232.x.x.xにマッピングされます。ここで、X.X.Xはエンティティグループ識別子の識別子サブフィールドの低次の24ビットです。
We use the following notation for Domain 1 entity identifiers <10> and propose it use as a standard convention.
ドメイン1エンティティ識別子<10>に次の表記を使用し、標準条約として使用することを提案します。
<flags>-<discriminator>-<Internet address>
where <flags> are [X]{BE,LE,RG,UG}[A]
X = reserved BE = big-endian entity LE = little-endian entity RG = restricted group UG = unrestricted group A = alias
x =予約済みbe =ビッグエンディアンエンティティle =リトルエンディアンエンティティrg =制限グループug =無制限のグループa =エイリアス
and <discriminator> is a decimal integer and <Internet address> is in standard dotted decimal IP address notation.
<差別>は小数整数であり、<インターネットアドレス>は標準の点線の小数点以下のIPアドレス表記です。
V.1. Authentication Domain 1
V.1. 認証ドメイン1
A principal identifier is structured as follows.
主な識別子は次のように構成されています。
+---------------------------+------------------------+
| Internet Address | Local User Identifier |
+---------------------------+------------------------+
32 bits 32 bits
VI. IP Implementation
vi。IP実装
VMTP is designed to be implemented on the DoD IP Internet Datagram Protocol (although it may also be implemented as a local network protocol directly in "raw" network packets.)
VMTPは、DOD IP Internet Datagramプロトコルに実装されるように設計されています（ただし、「RAW」ネットワークパケットにローカルネットワークプロトコルとして直接実装される場合があります。）
The well-known entity identifiers specified to date are:
これまでに指定された有名なエンティティ識別子は次のとおりです。
VMTP_MANAGER_GROUP RG-1-224.0.1.0 Managers for VMTP operations.
vmtp_manager_group RG-1-224.0.1.0 VMTPオペレーションのマネージャー。
VMTP_DEFAULT_BECLIENT BE-1-224.0.1.0 Client entity identifier to use when a (big-endian) host has not determined or been allocated any client entity identifiers.
VMTP_DEFAULT_BECLIENT BE-1-224.0.1.0クライアントエンティティ識別子が決定または割り当てられていない場合、使用するクライアントエンティティ識別子。
VMTP_DEFAULT_LECLIENT LE-1-224.0.1.0 Client entity identifier to use when a (little-endian) host has not determined or been allocated any client entity identifiers.
VMTP_DEFAULT_LECLIENT LE-1-224.0.1.0クライアントエンティティ識別子が決定または割り当てられていない、または割り当てられていない場合に使用するクライアントエンティティ識別子。
Note that 224.0.1.0 is the host group address assigned to VMTP and to which all VMTP hosts belong.
224.0.1.0は、VMTPに割り当てられたホストグループアドレスであり、すべてのVMTPホストが属することに注意してください。
6.05. RFC 1146 TCP alternate checksum options
6.05. RFC 1146 TCP代替チェックサムオプション
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
6.06. RFC 1151 Version 2 of the Reliable Data Protocol (RDP)
6.06. 信頼できるデータプロトコル（RDP）のRFC 1151バージョン2
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
6.07. RFC 1644 T/TCP -- TCP Extensions for Transactions Functional Specification
6.07. RFC 1644 T/TCP -TCPトランザクションの機能仕様のための拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
6.08. RFC 1693 An Extension to TCP : Partial Order Service
6.08. RFC 1693 TCPへの拡張：部分注文サービス
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
6.09. RFC 1791 TCP And UDP Over IPX Networks With Fixed Path MTU
6.09. RFC 1791 TCPおよびUDPは、固定パスMTUを備えたIPXネットワークを介して
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
6.10. RFC 2343 RTP Payload Format for Bundled MPEG
6.10. バンドルされたMPEG用のRFC 2343 RTPペイロード形式
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
6.11. RFC 2582 The NewReno Modification to TCP's Fast Recovery Algorithm
6.11. RFC 2582 TCPの高速回復アルゴリズムへのNewreno修正
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
6.12. RFC 2762 Sampling of the Group Membership in RTP
6.12. RFC 2762 RTPのグループメンバーシップのサンプリング
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
6.13. RFC 2859 A Time Sliding Window Three Colour Marker (TSWTCM)
6.13. RFC 2859タイムスライドウィンドウ3色マーカー（TSWTCM）
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
6.14. RFC 2861 TCP Congestion Window Validation
6.14. RFC 2861 TCP混雑ウィンドウの検証
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
6.15. RFC 2909 The Multicast Address-Set Claim (MASC) Protocol
6.15. RFC 2909マルチキャストアドレスセットクレーム（MASC）プロトコル
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
In the initial survey of RFCs 24 positives were identified out of a total of 104, broken down as follows:
RFCSの最初の調査では、24の陽性が合計104から特定され、次のように分類されました。
Standards: 3 out of 5 or 60.00% Draft Standards: 0 out of 2 or 0.00% Proposed Standards: 17 out of 82 or 20.73% Experimental RFCs: 4 out of 15 or 26.67%
標準：5または60.00％のドラフト基準のうち3つの基準：2または0.00％提案された基準：82または20.73％の実験RFCS：15または26.67％のうち4
Of those identified many require no action because they document outdated and unused protocols, while others are document protocols that are actively being updated by the appropriate working groups. Additionally there are many instances of standards that SHOULD be updated but do not cause any operational impact if they are not updated. The remaining instances are documented below.
特定された人のうち、多くは時代遅れで未使用のプロトコルを文書化するため、アクションは必要ありませんが、他の人は適切なワーキンググループによって積極的に更新されているドキュメントプロトコルです。さらに、更新する必要があるが、更新されていない場合は運用上の影響を引き起こさない標準の多くのインスタンスがあります。残りのインスタンスは以下に文書化されています。
7.1.1. STD 7 Transmission Control Protocol (RFC 793)
7.1.1. STD 7トランスミッションコントロールプロトコル（RFC 793）
Section 3.1 defines the technique for computing the TCP checksum that uses the 32 bit source and destination IPv4 addresses. This problem is addressed in RFC 2460 Section 8.1.
セクション3.1は、32ビットソースと宛先IPv4アドレスを使用するTCPチェックサムを計算する手法を定義しています。この問題は、RFC 2460セクション8.1で説明されています。
7.1.2. STD 19 Netbios over TCP/UDP (RFCs 1001 & 1002)
7.1.2. TCP/UDP上のSTD 19 NetBios（RFCS 1001および1002）
These two RFCs have many inherent IPv4 assumptions and a new set of protocols must be defined.
これらの2つのRFCには、多くの固有のIPv4仮定があり、新しい一連のプロトコルを定義する必要があります。
7.1.3. STD 35 ISO Transport over TCP (RFC 1006)
7.1.3. STD 35 ISOトランスポートTCP（RFC 1006）
This problem has been fixed in RFC 2126, ISO Transport Service on top of TCP.
この問題は、TCPの上にあるISO輸送サービスのRFC 2126で修正されています。
There are no draft standards within the scope of this document.
このドキュメントの範囲内にドラフト基準はありません。
7.3.01. TCP/IP Header Compression over Slow Serial Links (RFC 1144)
7.3.01. 遅いシリアルリンク上のTCP/IPヘッダー圧縮（RFC 1144）
This problem has been resolved in RFC2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. See also RFC 2507 & RFC 2509.
この問題はRFC2508で解決され、低速シリアルリンクのIP/UDP/RTPヘッダーを圧縮しています。RFC 2507およびRFC 2509も参照してください。
7.3.02. ONC RPC v2 (RFC 1833)
7.3.02. ONC RPC V2（RFC 1833）
The problems can be resolved with a definition of the NC_INET6 protocol family.
問題は、NC_INET6プロトコルファミリーの定義で解決できます。
7.3.03. RTSP (RFC 2326)
7.3.03. RTSP（RFC 2326）
Problem has been acknowledged by the RTSP developer group and will be addressed in the move from Proposed to Draft Standard. This problem is also addressed in RFC 2732, IPv6 Literal Addresses in URL's.
問題はRTSP開発者グループによって認められており、提案されたドラフト標準への移行で対処されます。この問題は、RFC 2732、IPv6リテラルアドレスのURLのアドレスにも宛てられています。
7.3.04. SDP (RFC 2327)
7.3.04. SDP（RFC 2327）
One problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. The other problem can be addressed with a minor textual clarification. This must be done if the document is to transition from Proposed to Draft. These problems are solved by documents currently in Auth48 or IESG discuss.
1つの問題は、RFC 2732、URLのIPv6リテラルアドレスで対処されています。他の問題は、マイナーなテキストの明確化で対処できます。これは、ドキュメントが提案されたドラフトからドラフトに移行する場合に行う必要があります。これらの問題は、現在AUTH48またはIESGディスカッションにあるドキュメントによって解決されます。
7.3.05. IPPM Metrics (RFC 2678)
7.3.05. IPPMメトリック（RFC 2678）
The IPPM WG is working to resolve these issues.
IPPM WGは、これらの問題の解決に取り組んでいます。
7.3.06. IPPM One Way Delay Metric for IPPM (RFC 2679)
7.3.06. IPPM IPPMの片道遅延メトリック（RFC 2679）
The IPPM WG is working to resolve these issues. An ID is available (draft-ietf-ippm-owdp-03.txt).
IPPM WGは、これらの問題の解決に取り組んでいます。IDが利用可能です（draft-itf-ippm-owdp-03.txt）。
7.3.07. IPPM One Way Packet Loss Metric for IPPM (RFC 2680)
7.3.07. IPPM IPPMの片道パケット損失メトリック（RFC 2680）
The IPPM WG is working to resolve these issues.
IPPM WGは、これらの問題の解決に取り組んでいます。
7.3.09. Round Trip Delay Metric for IPPM (RFC 2681)
7.3.09. IPPMの往復遅延メトリック（RFC 2681）
The IPPM WG is working to resolve these issues.
IPPM WGは、これらの問題の解決に取り組んでいます。
7.3.08. The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services(RFC 2848)
7.3.08. パイントサービスプロトコル：電話サービスへのIPアクセスのためのSIPおよびSDPへの拡張（RFC 2848）
This specification is dependent on SDP which has IPv4 dependencies. Once these limitations are fixed, then this protocol should support IPv6.
この仕様は、IPv4依存関係を持つSDPに依存します。これらの制限が修正されると、このプロトコルはIPv6をサポートする必要があります。
7.3.09. TCP Processing of the IPv4 Precedence Field (RFC 2873)
7.3.09. IPv4優先順位フィールドのTCP処理（RFC 2873）
The problems are not being addressed.
問題は対処されていません。
7.3.10. Integrated Services in the Presence of Compressible Flows (RFC 3006)
7.3.10. 圧縮性フローの存在下での統合サービス（RFC 3006）
This document defines a protocol that discusses compressible flows, but only in an IPv4 context. When IPv6 compressible flows are defined, a similar technique should also be defined.
このドキュメントでは、圧縮性フローについて議論するプロトコルを定義しますが、IPv4コンテキストでのみです。IPv6圧縮性フローが定義されている場合、同様の手法も定義する必要があります。
7.3.11. SDP For ATM Bearer Connections (RFC 3108)
7.3.11. ATMベアラー接続用SDP（RFC 3108）
The problems are not being addressed, but it is unclear whether the specification is being used.
問題は対処されていませんが、仕様が使用されているかどうかは不明です。
7.3.12. The Congestion Manager (RFC 3124)
7.3.12. 混雑マネージャー（RFC 3124）
An update to this document can be simply define the use of the IPv6 Traffic Class field since it is defined to be exactly the same as the IPv4 TOS field.
このドキュメントの更新は、IPv4 TOSフィールドとまったく同じと定義されるため、IPv6トラフィッククラスフィールドの使用を単純に定義できます。
7.4.1. Reliable Data Protocol (RFC 908)
7.4.1. 信頼できるデータプロトコル（RFC 908）
This specification relies on IPv4 and a new protocol standard may be produced.
この仕様はIPv4に依存しており、新しいプロトコル標準が生成される場合があります。
7.4.2. Internet Reliable Transaction Protocol functional and interface specification (RFC 938)
7.4.2. インターネット信頼できるトランザクションプロトコル機能およびインターフェイス仕様（RFC 938）
This specification relies on IPv4 and a new protocol standard may be produced.
この仕様はIPv4に依存しており、新しいプロトコル標準が生成される場合があります。
7.4.3. NETBLT: A bulk data transfer protocol (RFC 998)
7.4.3. NetBlt：バルクデータ転送プロトコル（RFC 998）
This specification relies on IPv4 and a new protocol standard may be produced.
この仕様はIPv4に依存しており、新しいプロトコル標準が生成される場合があります。
7.4.4. VMTP: Versatile Message Transaction Protocol (RFC 1045)
7.4.4. VMTP：汎用メッセージトランザクションプロトコル（RFC 1045）
This specification relies on IPv4 and a new protocol standard may be produced.
この仕様はIPv4に依存しており、新しいプロトコル標準が生成される場合があります。
7.4.5. OSPF over ATM and Proxy-PAR (RFC 2844)
7.4.5. ATM上のOSPFおよびProxy-Par（RFC 2844）
This specification relies on IPv4 and a new protocol standard may be produced.
この仕様はIPv4に依存しており、新しいプロトコル標準が生成される場合があります。
This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself.
このメモでは、仕様のIPv6対応を調べます。これにはセキュリティ上の考慮事項はありません。
The authors would like to acknowledge the support of the Internet Society in the research and production of this document. Additionally the author, Philip J. Nesser II, would like to thanks his partner in all ways, Wendy M. Nesser.
著者は、この文書の研究と制作におけるインターネット社会の支援を認めたいと考えています。さらに、著者のフィリップ・J・ネッサーIIは、あらゆる点で彼のパートナー、ウェンディ・M・ネッサーに感謝したいと思います。
The editor, Andreas Bergstrom, would like to thank Pekka Savola for guidance and collection of comments for the editing of this document. He would further like to thank Allison Mankin, Magnus Westerlund and Colin Perkins for valuable feedback on some points of this document.
編集者のアンドレアス・バーグストロムは、このドキュメントの編集に関するコメントのガイダンスとコレクションについて、Pekka Savolaに感謝したいと思います。彼はさらに、この文書のいくつかのポイントに関する貴重なフィードバックをしてくれたアリソン・マンキン、マグナス・ウェスターランド、コリン・パーキンスに感謝したいと思います。
[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月。
Please contact the authors with any questions, comments or suggestions at:
質問、コメント、または提案については、著者に連絡してください。
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 48
EMail: phil@nesser.com
Andreas Bergstrom, Editor Ostfold University College Rute 503 Buer N-1766 Halden Norway
Andreas Bergstrom、編集者Ostfold University College Rute 503 Buer N-1766 Halden Norway
EMail: andreas.bergstrom@hiof.no
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エディター機能の資金は現在、インターネット協会によって提供されています。